This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Define _POSIX_SOURCE in cygwin's features.h?

Hash: SHA1

According to Christopher Faylor on 1/12/2006 10:31 AM:
> Someone on the cygwin irc channel had a problem building a package which
> would have been solved if Cygwin defined _POSIX_SOURCE.
> I know that Cygwin is not fully POSIX compliant (I really really do) but
> I'm wondering if setting _POSIX_SOURCE in the cygwin headers wouldn't
> solve more porting problems than it creates.
> Any opinions on this?  Eric?

Well, since you asked me (what, am I now the POSIX guru?), POSIX has this
to say about it:

It is the responsibility of a POSIX-conformant app to define _POSIX_SOURCE
to 1 if they want compliance with the 1992 version of POSIX.1, or to
define _POSIX_C_SOURCE to 200112L if they want compliance with the 2001
version of POSIX.  The definition must occur in the application's file
before the inclusion of any standard header.  By defining _POSIX*SOURCE,
the application is specifically requesting that all namespace variables
required or reserved by POSIX are visible, and no functions not required
by POSIX and not in a reserved namespace are hidden, unless additional
feature macros were also defined.  (For example, defining _XOPEN_SOURCE to
600 is an additional feature macro to pull in the X headers.)  In fact,
POSIX states that defining only _XOPEN_SOURCE=600 is good enough that the
system headers should then turn on _POSIX_C_SOURCE=200112L.

Now what does this all mean to cygwin?  Most apps don't care about strict
compliance - they are more than willing to use extensions if it makes it
easier to get the job done, so most apps don't define _POSIX_SOURCE or
_POSIX_C_SOURCE before including headers.  I agree with Samuel's
conclusion - we can use the Linux trick of having a default configuration
of gcc that turns on _GNU_SOURCE (itself a feature test, that turns on all
other extensions), provided that gcc can also be told to be strictly
compliant to a given standard (gcc's -ansi flag, among others).  Then,
when _GNU_SOURCE is defined, cygwin can also define _POSIX_SOURCE under
the hood to allow developers to be lazy and not explicitly define it
themselves when they don't care about strict compliance.  In other words,
the goal should be that unless the user EXPLICITLY asked for a certain
namespace, by defining _POSIX_C_SOURCE themselves, we might as well be
generous and give them everything.

> P.S.  I know that Cygwin isn't fully compliant with POSIX specifications.

One other thing to be aware of.  If cygwin does define _POSIX2_VERSION in
its headers, programs will assume that all features specified by POSIX are
available.  Coreutils, in particular, makes a compile-time decision about
the default behavior of some of its apps, based on the value of
_POSIX2_VERSION (of course, this decision is overridable at runtime by
redefining _POSIX2_VERSION in the environment).  An example of this would
be that right now on cygwin, with coreutils 5.93, "tail +4" defaults to
the 1992 POSIX semantics of "tail -n +4", because _POSIX2_VERSION was not
detected at configure time.  But if you start adding _POSIX* macros to
features.h, to be more like Linux, and choose to move to the 2001 version
of POSIX, then a recompilation of "tail +4" would default to the semantics
of "tail ./+4".

- --
Life is short - so eat dessert first!

Eric Blake   
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at
Comment: Using GnuPG with Thunderbird -


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]