Re: daemon.c broken on OpenBSD

Linus Torvalds wrote:
> 
> 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.

> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html