Re: [OT] ABI vs. API

["Monique Y. Herman" <spam@bounceswoosh.org>]

On 2004-02-04, Colin Watson penned:
>
[snip]
> An API is the source code interface to a library. So, for instance,
> this is an API, together with the description of what the functions
> do, how you're allowed to use them, and what the arguments and return
> values mean:
>
>        #include <stdio.h>
>
>        FILE *fopen(const char *path, const char *mode); FILE
>        *fdopen(int fildes, const char *mode); FILE *freopen(const char
>        *path, const char *mode, FILE *stream);
>
> An ABI is the interface to a library as seen by compiled code. To
> figure out the ABI for the above, you need to know things like which
> way round the bytes in an int go, how long a pointer is, and where the
> arguments go on the stack when you're calling a function. More
> complicated and library-specific ABIs include things like the way
> elements in a struct are laid out.
>
[snip]

Let me reword this to make sure I "get" it.

An API is a contract that the author of a set of methods (I'd call them
libraries, but this seems to be an overloaded term) provides to the user
of these methods.  The contract defines the legal method signatures.

An ABI could be the compiled implementation of an API.  Even if the API
doesn't change, the ABI will change if the author changes the
implementation of a method.

When I'm writing code, I need to concern myself with the API.  When I'm
compiling/linking an app, I need to concern myself with the ABI.  I
might not need to know exactly what in the ABI has changed, but I
certainly need to know *if* it has changed.

Is that about right?

-- 
monique