Message-ID: <43C7BD94.7090704@byu.net>
Date: Fri, 13 Jan 2006 07:47:48 -0700
From: Eric Blake <ebb9 AT byu DOT net>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Define _POSIX_SOURCE in cygwin's features.h?
References: <20060112173104 DOT GA30011 AT trixie DOT casa DOT cgf DOT cx>
In-Reply-To: <20060112173104.GA30011@trixie.casa.cgf.cx>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

-----BEGIN PGP SIGNED MESSAGE-----
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:
http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_02.html

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             ebb9 AT byu DOT net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDx72U84KuGfSFAYARAhzrAKCXvG9T8qf/jC72EiOfkV47h+Kr4wCdHXaQ
d72MLCP3eLQR4qIgITkiYn4=
=YNn9
-----END PGP SIGNATURE-----

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/