On Mon, Aug 12, 2002 at 06:28:16PM +0100, Ben Harris wrote:
> On Mon, 12 Aug 2002, Martin Weber wrote:
> 
> > On Mon, Aug 12, 2002 at 05:48:05PM +0100, Ben Harris wrote:
> > > [... Name clashes of utils in libc headers with own stuff ...]
> > >
> > > One way to avoid this is to #define a feature-test macro like _POSIX_SOURCE.
> > > That will prevent the include files defining anything that the relevant
> > > standard doesn't permit.  This might be a little too restrictive for you,
> > > though.
> >
> > Could also do it the solaris way, #define _EXTENSIONS :) (or was it EXTENSIONS?)
> > (i.e. leave the utils like fparseln etc. out of the corresponding
> > headers if EXTENSIONS is not defined in the including code environment)
> 
> So what do you get if you don't define _EXTENSIONS?  Is it 4.3BSD, 4.4BSD,
> IEEE Std 1003.1-1988, IEEE Std 1003.1-1990, ISO/IEC 9945-1:1996
> IEEE Std 1003.1-2001, XPG1, XPG2, XPG3, XPG4, XPG5, XPG6, or something
> else entirely?  And having chosen, are we allowed to change the base when
> a new standard comes out?

If you don't define _EXTENSIONS you get what you get now by the libc-related
header files, if you define it you get the stuff which is said to be not fitting
into libutil if you include the right header, as easy.

So, to riposte :p What do you get now without anything defined if you include
unistd.h ? IEEE Std anything ? XPG1,2,3,4... ?

I was merely meaning to put the stuff which is said to be not fitting 
into libutil, and which seemingly wants to be put in libc, into #ifdef _EXTENSIONS;
if you want to use it, define it, else don't and be at the same point
as you are now, don't see where's your problem ?

You said yourself, asking explicitely for some standard might be too
restricting.

-Martin