Date:	Fri, 13 Feb 1998 13:07:22 +0100 (MET)
From:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
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:	<Pine.LNX.3.93.980213125441.3039B-100000@acp3bf>
MIME-Version:	1.0

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 <ctype.h>
	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.

- Raw text -