Use of _XOPEN_SOURCE?

[Marco Atzeri]

--- Mar 2/3/10, Jeff Johnston  ha scritto:

> Patch applied.  Thanks Craig.
> 
> -- Jeff J.
> 
> On 01/03/10 04:04 PM, Howland Craig D (Craig) wrote:
> > I have put it into sys/features.h and included
> sys/features.h at the
> > beginning of sys/config.h, as you suggest.  The
> patch is attached.  I
> > built it under Cygwin and Linux and nothing failed.
> >
> > I noticed one thing that makes me wonder slightly as
> to whether it
> > would need addressing is that in sys/unistd.h, line
> 260 includes
> > sys/features.h, but this is after a check for
> _POSIX_SOURCE, the
> > old (1990) form of _POSIX_C_SOURCE (line 196). 
> It's only gating one
> > function prototype (vfork()).  IF we were to
> later try to attempt to
> > do something with _POSIX_SOURCE, the prior inclusion
> of sys/features.h
> > (due to being pulled in at the top) MIGHT make a
> difference.  I'm
> > thinking that this is not worth worrying about.
> >
> > Speaking of _POSIX_SOURCE, it appears in 19 files
> under libc, all of
> > which are just checks for it.  Something to do
> later.  (A note for
> > the mailing list archive as a reminder for when we
> might:  2001 says
> > "Since _POSIX_SOURCE specified by the POSIX.1-1990
> standard did not have
> > a value associated with it, the _POSIX_C_SOURCE macro
> replaces it,
> > allowing an application to inform the system of the
> revision of the
> > standard to which it conforms. This symbol will allow
> implementations to
> > support various revisions of IEEE Std 1003.1-2001
> simultaneously. For
> > instance, when either _POSIX_SOURCE is defined or
> _POSIX_C_SOURCE is
> > defined as 1, the system should make visible the same
> name space as
> > permitted and required by the POSIX.1-1990 standard.
> When
> > _POSIX_C_SOURCE is defined, the state of _POSIX_SOURCE
> is completely
> > irrelevant.")
> >
> > A secondary question:  given that this change now
> makes anything that
> > includes any system header end up with sys/features.h,
> should a cleanup
> > be done to take out all
> #include<sys/features.h>  to avoid confusion?
> > Or would it be worse for them to not have it and be
> assumed?  (It's
> > obviously easier to do nothing.)
> >
> > Craig
> >
> >
> > -----Original Message-----
> > From: Jeff Johnston [mailto:jjohnstn@redhat.com]
> > Sent: Thursday, February 25, 2010 12:44 PM
> > To: Howland Craig D (Craig)
> > Cc: Newlib
> > Subject: Re: Use of _XOPEN_SOURCE?
> >
> > I'm thinking this might be better situated in
> sys/features.h at the
> > bottom and then have sys/config.h include
> sys/features.h or
> > alternatively still have sys/config.h include
> sys/features.h before this
> >
> > check.  This would be along the lines of glibc
> where features.h is used
> > everywhere.
> >
> > -- Jeff J.
> 
> 
Hi Howland,
building octave on cygwin I catched an issue, as

on  /usr/include/sys/features.h
( newlib/libc/include/sys/features.h )
we have:

-------------------------------------------------------
#if !defined(_POSIX_C_SOURCE)  &&  defined(_XOPEN_SOURCE)
  #if _XOPEN_SOURCE == 700      /* POSIX.1-2008 */
    #define _POSIX_C_SOURCE       200809L
   #elif _XOPEN_SOURCE == 600   /* POSIX.1-2001 */
    #define _POSIX_C_SOURCE       200112L
  #endif
#endif
-------------------------------------------------------

this test expect that _XOPEN_SOURCE, when defined, has some
values.

However it seems that it could also be defined and empty:
http://docs.sun.com/app/docs/doc/816-5175/6mbba7f3p?a=view

so a definition like the one used on octave
    #define _XOPEN_SOURCE

is possible. In this case the compilation fails with :
/usr/include/sys/features.h:189:21: error: operator '==' has no left operand
/usr/include/sys/features.h:191:24: error: operator '==' has no left operand

Could you add also this case ?

Thanks
Marco