On Wed, 2003-01-08 at 19:57, Steve Langasek wrote:
> On Wed, Jan 08, 2003 at 01:28:58PM -0500, H. S. Teoh wrote:
>
> > Umm... if I were an upstream author, I'd choose the soname based on the
> > API.
>
> Then you're not fit to be an upstream library author, because you don't
> understand that an ABI can change *as a result of changes you make*,
> without any corresponding changes to the API. One example of this is
> changing the size of a data type, which may provide complete source
> compatibility while completely breaking binary compatibility.
But changing the size of a datatype is, imho, an API change. The API is
more than just the names of the {functions|classes|types|...} - it's
their whole type. And a type has a size assigned to it.
Yes, I'm arguing that the compiler can force API changes when the size
of int (or something like that) changes. Modern language standards
thankfully provide means to avoid that (using wuzzit uint_32 instead of
plain int etc.).
In my understanding:
API == the set of exported symbols of a library (module/package/......)
with their types and other attributes
ABI == how these symbols are encoded so that the loader/linker can merge
objects to a memory image ready to be executed.
The issues are closely interdependent, of course, so there'll probably
always be some grey areas.
cheers
-- vbi
--
> I'm an idiot.. At least this [bug] took about 5 minutes to find..
Surely, Linus is talking about the kind of idiocy that others aspire to :-).
-- Bruce Perens in response to Linus Torvalds's
Attachment:
signature.asc
Description: This is a digitally signed message part