Re: [PATCH] Fix continuation problems on IA64.

[Neil Jerram]

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

> 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