From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] Fix continuation problems on IA64. Date: Fri, 09 May 2008 23:19:09 +0100 Message-ID: <87skwrce8y.fsf@ossau.uklinux.net> References: <87k5i5d6ei.fsf@ossau.uklinux.net> <87y76ksglg.fsf@gnu.org> <8763tomqn7.fsf@ossau.uklinux.net> <87lk2jhp0h.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1210371639 15468 80.91.229.12 (9 May 2008 22:20:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 9 May 2008 22:20:39 +0000 (UTC) Cc: guile-devel@gnu.org To: ludo@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat May 10 00:21:15 2008 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Juaxm-0008CR-EW for guile-devel@m.gmane.org; Sat, 10 May 2008 00:21:14 +0200 Original-Received: from localhost ([127.0.0.1]:60778 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Juax4-0003w5-2h for guile-devel@m.gmane.org; Fri, 09 May 2008 18:20:30 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Juavx-0003eT-BX for guile-devel@gnu.org; Fri, 09 May 2008 18:19:21 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Juavv-0003eH-OV for guile-devel@gnu.org; Fri, 09 May 2008 18:19:20 -0400 Original-Received: from [199.232.76.173] (port=59683 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Juavv-0003eE-IR for guile-devel@gnu.org; Fri, 09 May 2008 18:19:19 -0400 Original-Received: from mail3.uklinux.net ([80.84.72.33]:38371) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Juavr-00005K-3p; Fri, 09 May 2008 18:19:15 -0400 Original-Received: from arudy (host81-129-100-189.range81-129.btcentralplus.com [81.129.100.189]) by mail3.uklinux.net (Postfix) with ESMTP id CC1D11F6656; Fri, 9 May 2008 23:19:10 +0100 (BST) Original-Received: from laruns (laruns [192.168.0.10]) by arudy (Postfix) with ESMTP id 55B4C3800D; Fri, 9 May 2008 23:19:10 +0100 (BST) In-Reply-To: <87lk2jhp0h.fsf@gnu.org> (Ludovic =?iso-8859-1?Q?Court=E8s's?= message of "Fri, 09 May 2008 10:15:26 +0200") User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:7230 Archived-At: ludo@gnu.org (Ludovic Court=E8s) writes: > If we change the ABI, we should increase `LIBGUILE_INTERFACE_CURRENT' > and set `AGE' to zero because it's not going to be > backward-compatible---and we can't do that only for IA64, > unfortunately... Agreed, but I'm not sure the ABI is really changing... > Programs necessarily access it, through `SCM_I_CURRENT_THREAD', etc. Yes, but only as a pointer, whose only practical use is to pass back to other libguile functions. That usage doesn't require recompilation. Usages which would require recompilation are - accessing any particular fields in the scm_i_thread structure - declaring a scm_i_thread on the stack - allocating a scm_i_thread on the heap (or in general, anything involving "sizeof(scm_i_thread)"). In my view, all of these uses are unsupported, and I think it incredibly unlikely that anyone has done any of them in practice. Overall, then, I think we're OK to regard this as _not_ an ABI change. > Right, but `SCM_API' is just `extern' (except on Windows), which is > "normal" in such a declaration; I disagree that it is "normal" always to put `extern' on function prototypes. It isn't needed (as I'm sure you know), and I'm sure I could find lots of examples of projects that don't do it. > and whether declared `extern' or not, the symbol will be exported > anyway. True (except on Windows), but in my view being exported doesn't make something a supported API. I haven't checked again just now, but I think I've seen other cases where SCM_API is used on a prototype of a function that I would not regard as a supported libguile API. I dislike this, because the name SCM_API clearly implies that the prototype concerned is an API! I definitely don't think that we should create more cases like this. FWIW, my preferred position would be that something is only a supported API if it is documented in the manual. It should then follow that SCM_API can only be used on something that is documented in the manual (including anything that is needed for the expansions of documented macros). Regards, Neil