APIs and ABIs

Niall Douglas s_fsfeurope2 at nedprod.com
Sat May 15 22:47:06 UTC 2004

Hash: SHA1

On 15 May 2004 at 13:18, Neal H. Walfield wrote:

> > Both the GNU and BSD C libraries offer the same API's eg; size_t
> > fread(void *buffer, size_t size, size_t count, FILE *stream). Both
> > use the same compiler (GCC) and so therefore that API will convert
> > into the same ABI eg; _fread using the same parameter to stack
> > conversion mechanism (the procedural call convention).
> That is complete and utter crap.
> The ABI has nothing to do with the compiler: calling conventions, etc.
> are established by the operating system. 

No, the ABI is determined by what compiler the operating system was 
compiled with. C (and C++) implementations are free to choose any 
procedural calling convention they like. Contrast how Mingw and MSVC 
mangle their C++ symbols differently. Contrast even within MSVC how 
you can choose between three different calling conventions. On 
Windows at least two calling conventions are used throughout the OS 
depending on what the library designer felt like.

Go read either the ANSI C or ISO C++ spec if you want confirmation of 

> Nothing guarantees that
> posix defined structures have the same layout or even size (and this
> is very much part of the ABI).  Not all posix functions are actually
> functions, many of them may be macros.  The list goes on and this does
> not even consider versioning schemes, library dependencies or system
> trap calling conventions.

In the fread() example above, FILE is an opaque pointer. It could 
contain anything. For major structures eg; struct stat one finds an 
amazing invariance of fields and their order. If the structure 
packing were different one might have a problem, but again everyone 
using GCC solves that.

I only know this because I run my Linux and FreeBSD inside VMWare 
with them working on a common project tree on Windows via samba. I 
sometimes forget which machine I'm typing into and use the wrong 
object files and most unfortunately it'll sometimes link and run - 
though with weird runtime errors.


Version: idw's PGP-Frontend / 9-2003 + PGP 8.0.2


More information about the Discussion mailing list