Our testing needs work...

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> > Here is what's happening.  The ctype functions formally take an int, but
> > semantically take a char.  They're implemented by a macro that indexes a
> > hidden array.  The compiler is complaining because the array is being
> > indexed by an expression of non-integral type.  Which, in this case, is
> > silly. 
> 
> Does it do the right thing with negative chars?  I'd expect it to sign extend 
> and look ahead of the table.

According to the manual page and the standard, the domain of these functions
is unsigned char or EOF - behavior on negative signed characters is unspecified
and could invoke nasal demons.

> Is the table 256 slots long or only 128?  (or 384 with a duplicate copy of 
> the top half in front of the starting place)

The question has no answer that is reliable cross-platform.  I've
seen enough implementations to know that the ctype macros are often
done with magic arrays of flag bits, which is how I recognized the
problem - but it's not *guaranteed* to be implemented that way, much
less what happens in edge cases.

> esr at thyrsus.com said:
> > There's probably an option to suppress this check that defaults on but your
> > one build environment has inverted.  It would be nice to figure out what
> > that is. 
> 
> NetBSD and FreeBSD.

Can you find out what the compiler's default set of flags is?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>