Date:	Mon, 21 Nov 94 23:47:30 -0500
From:	dj AT stealth DOT ctron DOT com (DJ Delorie)
To:	djgpp AT sun DOT soe DOT clarkson DOT edu
Subject:	ansi/posix compatibility ideas and issues

In working on posix compatibility, I decided on a techinique similar
to what NT uses.  For all non-posix functions, the real function has
two underscores prepended (like __findfirst).  There is also a small
bit of assembler that defines the conventional name (like findfirst)
with a jump to the real function (ff: jmp __ff).  Thus, if your
program uses that symbol, the rest of libc can still get to the
function it expects without polluting your namespace.  I would have
used one underscore, but open and _open already each have meanings, so
I chose two underscores.

This part works OK.

One question is, should I use the same technique for functions that
are ansi but not posix, so that an ansi program can (for example)
provide a non-standard write() function and still expect printf() to
work as ansi documents?

The other question is the header files.  Presumably, I should include
both sets of prototypes (ff and __ff) so that you can use either and
be OK.  However, the headers are broken down into sections, protected
by various conditionals (like _POSIX_SOURCE).  Since the __ff-style
symbols don't violate POSIX but aren't part of POSIX, should they go
in the posix section or the non-posix section?  Basically, if you
declare yourself to be a _POSIX_SOURCE program, should the headers
provide prototypes for the __ff functions?

The same goes for ansi.  If you say you're a pure ansi program, should
you get prototypes for non-ansi functions that fall within the ansi
reserved name space?

- Raw text -