From: Junio C Hamano Date: Fri, 22 Dec 2006 08:37:41 GMT Subject: Re: [PATCH] Don't define _XOPEN_SOURCE on MacOSX and FreeBSD as it is too restricting Message-ID: <7v4pro5nsa.fsf@assigned-by-dhcp.cox.net> In-Reply-To: <20061222075142.GA9595@fiberbit.xs4all.nl> Marco Roeland writes: > 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. > 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.