Date: Fri, 13 Feb 1998 13:07:22 +0100 (MET) From: Hans-Bernhard Broeker To: andrewc AT rosemail DOT rose DOT hp DOT com cc: Vik DOT Heyndrickx AT rug DOT ac DOT be, dj AT delorie DOT com, djgpp-workers AT delorie DOT com Subject: Re: char != unsigned char... sometimes, sigh In-Reply-To: <199802121916.AA077810975@typhoon.rose.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Thu, 12 Feb 1998, Andrew Crabtree wrote: > > On Thu, 12 Feb 1998, Vik Heyndrickx wrote: > > > There is something nasty about inline externs. You have to put also a > > > version without 'inline extern' in the libc library. [...] > Actually, I thought that you *didn't* need to have a copy in an external > library. Its optional to do so, and required if somebody tries to > access the address of the function, but if people assume they are > macros then they won't do this. Sorry, but the ANSI Standard explicitly requires them to be available as functions as well. To cite it (from Plauger's 'The Standard C Library'): ---- from ANSI C Standard document, chapter 7.1.7: Any macro definition of a function can be suppressed locally by enclosing the name of the function in parentheses, because the name is then not followed by the left parenthesis that indicates expansion of a macro function name. For the same syntactic reason, it is permitted to take the address of a library function even if it is also defined as a macro ----- In simpler words, ANSI just told us that an ANSI-compliant program is expressly allowed to call, say, isalpha(), like this: #include char c = '\x84' /* or any other value */ int v = (isalpha)((unsigned char)c); and be sure that the isalpha() macro will *not* be used to evaluate this. So, not providing an actual function in libc would definitely break ANSI-compliance. Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Even if all the snow were burnt, ashes would remain.