From: Junio C Hamano <junkio@cox•net>
To: Marco Roeland <marco.roeland@xs4all•nl>
Cc: Terje Sten Bjerkseth <terje@bjerkseth•org>,
"Randal L. Schwartz" <merlyn@stonehenge•com>,
Linus Torvalds <torvalds@osdl•org>, Rocco Rutte <pdmef@gmx•net>,
git@vger•kernel.org
Subject: Re: [PATCH] Don't define _XOPEN_SOURCE on MacOSX and FreeBSD as it is too restricting
Date: Fri, 22 Dec 2006 00:37:41 -0800 [thread overview]
Message-ID: <7v4pro5nsa.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <20061222075142.GA9595@fiberbit.xs4all.nl> (Marco Roeland's message of "Fri, 22 Dec 2006 08:51:42 +0100")
Marco Roeland <marco.roeland@xs4all•nl> 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.
next prev parent reply other threads:[~2006-12-22 8:37 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-20 20:48 What's in git.git (stable), and Announcing GIT 1.4.4.3 Junio C Hamano
2006-12-20 22:04 ` Randal L. Schwartz
2006-12-20 22:14 ` Linus Torvalds
2006-12-20 22:20 ` [BUG] daemon.c blows up on OSX (was Re: What's in git.git (stable), and Announcing GIT 1.4.4.3) Randal L. Schwartz
2006-12-20 22:25 ` [BUG] daemon.c blows up on OSX Junio C Hamano
2006-12-20 22:35 ` Randal L. Schwartz
2006-12-20 22:44 ` Junio C Hamano
2006-12-20 22:46 ` Randal L. Schwartz
2006-12-20 23:03 ` Junio C Hamano
2006-12-20 23:25 ` Randal L. Schwartz
2006-12-20 23:34 ` Randal L. Schwartz
2006-12-21 2:04 ` Stefan Pfetzing
2006-12-20 23:07 ` Linus Torvalds
2006-12-20 23:17 ` Randal L. Schwartz
2006-12-20 23:30 ` Junio C Hamano
2006-12-20 23:41 ` Linus Torvalds
2006-12-21 0:36 ` Terje Sten Bjerkseth
2006-12-21 0:44 ` Junio C Hamano
2006-12-21 0:54 ` Terje Sten Bjerkseth
2006-12-21 1:00 ` Junio C Hamano
2006-12-21 1:20 ` Randal L. Schwartz
2006-12-21 1:29 ` Junio C Hamano
2006-12-21 1:35 ` Terje Sten Bjerkseth
2006-12-21 10:39 ` [PATCH] Do not define _XOPEN_SOURCE on MacOSX as it is too restricting there Marco Roeland
2006-12-21 11:28 ` [PATCH] Don't define _XOPEN_SOURCE on MacOSX and FreeBSD as it is too restricting Marco Roeland
2006-12-22 0:52 ` Junio C Hamano
2006-12-22 1:04 ` Shawn Pearce
2006-12-22 6:53 ` Rocco Rutte
2006-12-22 7:51 ` Marco Roeland
2006-12-22 8:37 ` Junio C Hamano [this message]
2006-12-22 11:47 ` Marco Roeland
2006-12-22 12:55 ` Rocco Rutte
2006-12-22 13:14 ` Marco Roeland
2007-01-03 15:25 ` [BUG] daemon.c blows up on OSX Andreas Ericsson
2006-12-21 0:44 ` Linus Torvalds
2006-12-21 1:07 ` Randal L. Schwartz
2006-12-21 1:13 ` Junio C Hamano
2006-12-21 1:08 ` Randal L. Schwartz
[not found] ` <24BF45E9-DD98-4609-9D65-B01EAA30CCA8@silverinsanity.com>
2006-12-21 1:35 ` Randal L. Schwartz
2006-12-21 1:48 ` Junio C Hamano
2006-12-21 1:50 ` Randal L. Schwartz
2006-12-21 1:57 ` Junio C Hamano
2006-12-20 23:58 ` What's in git.git (stable), and Announcing GIT 1.4.4.3 Randal L. Schwartz
2006-12-20 22:17 ` Junio C Hamano
2006-12-21 8:43 ` Johannes Schindelin
2006-12-21 8:52 ` Junio C Hamano
2006-12-20 22:19 ` Nicolas Pitre
2006-12-21 11:38 ` Johannes Schindelin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7v4pro5nsa.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox$(echo .)net \
--cc=git@vger$(echo .)kernel.org \
--cc=marco.roeland@xs4all$(echo .)nl \
--cc=merlyn@stonehenge$(echo .)com \
--cc=pdmef@gmx$(echo .)net \
--cc=terje@bjerkseth$(echo .)org \
--cc=torvalds@osdl$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox