Re: [PATCH] Don't define _XOPEN_SOURCE on MacOSX and FreeBSD as it is too restricting

From: Rocco Rutte <pdmef@gmx.net>
Date: Dec 22, 2006, 06:53 UTC
Message-ID: <20061222065327.GA3773@peter.daprodeges.fqdn.th-h.de>
In-Reply-To: <7v64c492fv.fsf@assigned-by-dhcp.cox.net>

Hi,

* Junio C Hamano [06-12-21 16:52:52 -0800] wrote:

>Marco Roeland <marco.roeland@xs4all.nl> writes:

>> We want our symbols "avilable" so lets not use _XOPEN_SOURCE on Darwin!

Show 5 quoted lines

>Personally, I think hiding interfaces such as strXXX and memXXX
>based on _XOPEN_SOURCE level is already a bug in the system
>header implementation.  The symbols that begin with str are
>already reserved by the standard and I do not see any point
>in the system headers to try avoiding namespace contamination.

Well, it depends, I'd say. Different strXXX functions may be introduced by different versions of standards and with _POSIX_C_SOURCE one can, for example, define to be compile for a specific standard version only.

>Two and half questions.

> #1   __APPLE__ vs __APPLE_CC__ is not something I can decide (I
>      do not run a Mac).  If MaxOS is derived from FreeBSD, does
>      it by chance define __FreeBSD as well?

> #2   Terje's patch excludes _XOPEN_SOURCE_EXTENDED as well on a
>      Mac, but yours doesn't.  Is there a reason that you would
>      want '#define _XOPEN_SOURCE_EXTENDED 1'?  Do both FreeBSD
>      and Mac behave well with it defined?

First of all, the combined patch posted is wrong since __FreeBSD doesn't work on FreeBSD, but __FreeBSD__ does.

Second, a grep over the FreeBSD headers in /usr/include shows that _XOPEN_SOURCE_EXTENDED only affects 2 curses header files, so it's safe to exclude it, i.e. define it for FreeBSD.

   bye, Rocco

-- 
:wq!