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

From: Junio C Hamano <junkio@cox.net>
Date: Dec 22, 2006, 08:37 UTC
Message-ID: <7v4pro5nsa.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20061222075142.GA9595@fiberbit.xs4all.nl>

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

Show 16 quoted lines

> On Thursday December 21st 2006 at 16:52 Junio C Hamano wrote:
>
>> 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.
>> 
>> But we are not in the business of fixing the system headers.
>
> ;-)
>
> Perhaps the idea behind this might be that it allows you to easier
> develop software that really only uses interfaces strictly defined in
> some "standards" to be always available on compliant platforms. That's
> all I could think of why you ever would want to do it like this yes.

(offtopic) Yeah, but my point was that ANSI C reserves _all_ symbols that begin with str ("Names reserved for expansion"), not just a specific set of functions like strcmp, strcpy, etc., so if a program tries to be compliant with it, it cannot use, for example, strncasecmp (was that the symbol we had trouble with?) for its own purpose anyway -- which means the system header implementation should not have to worry about namespace pollution. I do not see any reason for them to hide strncasecmp, for example.

Show 9 quoted lines

> On Apple compiling git works fine both with and without
> _XOPEN_SOURCES_EXTENDED. But looking in the headers, in contrast to the
> _XOPEN_SOURCE define which restricts functionality to some predefined
> set, the _XOPEN_SOURCES_EXTENDED only adds functionality and doesn't
> remove it. So I thought it might be best to keep as much symbols as
> possible to be the same for all platforms for future expandibility.
>
> Probably FreeBSD behaves the same with respect to
> _XOPEN_SOURCE_EXTENDED. Will check later today.

Ok, thanks.