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.
> Two and half questions.
>
> #0.5 Have you checked the tip of 'master' that has Terje's
> patch? It was reported to work yesterday and that is what
> was committed already.
For some reason a normal "pull" didn't show this one here yet. But I can
see it by merging. The commit "c902c9a" that I now see from Terje does
indeed work here. At any rate that one alone doesn't fix the (same)
FreeBSD issue as reported by Rocco Rutte who sent in an almost identical
patch but with the __FreeBSD__ define.
> #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?
As far as I know __APPLE__ is the preferred way of finding out we're
running for a Darwin target. Someone mentioned that __APPLE_CC__ was not
introduced until Apple OS X 10.4. It's value here ('5367') is the build
version of the Apple gcc compiler, doesn't seem very standardized. The
__APPLE__ macro is defined as '1'.
Unfortunately no there is _not_ any "BSD" like macro defined here, so no
__FreeBSD or something. And interesting enough we already know that
OpenBSD specifically needs the _XOPEN_SOURCE define. Anyone out there
with a NetBSD box so we can fix that 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?
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.
I don't know if the "Apple Public Source License" allows me to put the
Darwin system headers in a publicly accessable place, so I won't do
that, but if people are interested I can of course privately provide the
system headers and predefined symbols for anyone interested.
--
Marco Roeland
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html