On Fri, May 31, 2002 at 07:16:01PM +0100, Ben Harris wrote:
> In article <GwzK2v.H4E@tac.nyc.ny.us> you write:
> >In article <E17DpXi-0005ZP-00@chiark.greenend.org.uk>,
> >Ben Harris <bjh21@netbsd.org> wrote:
> >>On a system with signed chars, I think UPEOF will end up being just -1.

nope - should be 255

> >>
> >>In either case, I don't think any of those comparisons is "always true", so
> >>I'm confused.
> >
> >for systems with signed chars this ended up being
> >
> >#define UPEOF -129
> >
> >which is out of range for char. (it has been fixed)
> 
> Ah.  I hadn't noticed the strange dance being done with "base" in the signed
> case.

Because it isn't! dunno where -129 might come from!

#define UPEOF ((unsigned char) -1) 
int main ( int ac, char *av )
{
	char c = UPEOF;
	printf( "%d %d\n", UPEOF, c );
	return 0;
}

generates the expected output of "255 -1". (gcc 2.95.3 i386)

Since C requires that small integral types be converted to
int before any arithmetic is done the '*p != UPEOF' is
always comparing something with domain [-128..127] with 255.
Stopping the compiler bleating is actually quite hard [1] - OTOH
I bet the test does need to suceed sometimes!

[1] if you can change your source, the compiler writer can
enhance the domain tracking of integer vrariables....

	David

-- 
David Laight: david@l8s.co.uk