On Mon, 12 Aug 2002, Martin Weber wrote:

> 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.

By "what you get now" do you mean the precise set of functions present on
2002-08-22, or is that set allowed to grow?  If it's allowed to grow,
der Mouse's problem will still occur.

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

You get all the functions defined in libc (well, you do if you include all
the header files).  This is a superset of the set of functions you can get
with any given feature test macro, so you're guaranteed to be able to use
any function.

> 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 ?

I don't see why 2002-08-12 should be the magical cut-off.  Why heapsort()
should be available by default, but fparseln() shouldn't.

Perhaps a more useful mechanism would be to have a _NETBSD_SOURCE macro,
defining which says that you don't want anything introduced after a given
date visible.  So having determined that your code worked today, you could
#define _NETBSD_SOURCE 20020812, and you wouldn't get any nasty surprises
from compiling against newer headers.

-- 
Ben Harris                                                   <bjh21@netbsd.org>
Portmaster, NetBSD/acorn26           <URL:http://www.netbsd.org/Ports/acorn26/>