Re: daemon.c broken on OpenBSD

From: H. Peter Anvin <hpa@zytor.com>
Date: Oct 24, 2005, 17:26 UTC
Message-ID: <435D1963.8070205@zytor.com>
In-Reply-To: <Pine.LNX.4.64.0510241002180.10477@g5.osdl.org>

Linus Torvalds wrote:

Show 14 quoted lines

> 
> Side note: "safe in practice" isn't necessarily the same as "safe in 
> theory".
> 
> I think that strictly speaking, if you include <ctype.h>, the "isxxxx()" 
> format is always reserved (where "x" is lowercase letters), and in theory 
> you could have a compiler that recognizes them even before the 
> pre-processor as being something built-in.
> 
> In _practice_, such a compiler would be incredibly broken (it would have 
> to do the recognition after preprocessing too), and I doubt you'd ever see 
> such a thing, but from a pure language-lawyer standpoint it might 
> technically be possible.
>

A much more likely cause for problems would be system headers that use the isxxx() macros as part of other macros. That would be in violation of POSIX, but is reasonably common.

Show 5 quoted lines

> However, I'm surprised that you see <ctype.h> at all. The OpenBSD headers 
> seem to be including <ctype.h> from <sys/poll.h>, which doesn't make any 
> sense. It may not be strictly against POSIX, but it's definitely strange 
> and bad form to do unnecessary name pollution that the user didn't ask 
> for.

It is strictly against POSIX, but again, fairly common.

> So git actually tries to be pretty good about things. Not only does it try 
> to handle any existing system <ctype.h> by doing the #undef, it actually 
> doesn't include the system ctype.h at _all_ when it includes "cache.h". 
> And OpenBSD is being a bit strange.

I think there is another good reason for doing the renaming bit: we're creating new macros with different semantics; in particular, the git macros handle signed char input and don't guarantee anything w.r.t. EOF.

	-hpa