From: H. Peter Anvin Date: Mon, 24 Oct 2005 17:26:59 GMT Subject: Re: daemon.c broken on OpenBSD Message-ID: <435D1963.8070205@zytor.com> In-Reply-To: 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 , 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 at all. The OpenBSD headers > seem to be including from , 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 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