guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Fix continuation problems on IA64.


From: Ludovic Courtès
Subject: Re: [PATCH] Fix continuation problems on IA64.
Date: Sun, 11 May 2008 05:06:08 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)

Hi,

Neil Jerram <address@hidden> writes:

> address@hidden (Ludovic Courtès) 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...

Hmm, indeed, `scm_i_thread' is publicly visible but no public macro or
inline function uses it, so it's probably safe to change it (maybe we
should have an "internal.h" header for such things?).

> Overall, then, I think we're OK to regard this as _not_ an ABI change.

Yes, you're right.

> 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.

Right, that's admittedly more a matter of taste (indeed, `extern' is
equivalent to no storage-class specifier per Paragraph 5, Section 6.2.2
of C99).

> 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.

I'm not a Windows expert, but I think the `SCM_API' is needed in some
cases, for instance for internal `scm_i_' functions that may be called
indirectly by user programs, e.g., through macros or inline functions.

So I suppose `SCM_API' is not needed Windows-wise for `scm_ia64_longjmp'
since it's only meant to be called from within libguile.

> 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).

Agreed.

I've been thinking about leveraging GCC's `visibility' attribute to
enforce this.

Thanks,
Ludovic.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]