Sender:	vheyndri AT rug DOT ac DOT be
Message-Id:	<34D185D3.302@rug.ac.be>
Date:	Fri, 30 Jan 1998 08:48:35 +0100
From:	Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
Mime-Version:	1.0
To:	djgpp-workers AT delorie DOT com
Subject:	Re: char != unsigned char... sometimes, sigh
References:	<Pine DOT SOL DOT 3 DOT 95 DOT 971219123655 DOT 1932A-100000 AT dumballah DOT tvnet DOT hu>

Olla workers,

Another thought to support the idea for changing the 'char' default from
'signed char' to 'unsigned char' is that the is* macros from <ctype.h>
are ALL buggy because they do not select the proper array element for
the argument being EOF.

The standard tells that the is* macros should work for any value in the
'unsigned char' range and for EOF (equals to -1 in our case).

This bug is actually triggered because 'char' defaults to 'signed char'.
Because a LOT of programs actually rely on the fact that the is* macros
should work on a 'char', someone made this macro cast the 'c' argument
to an 'unsigned char' (i.e. ANDs it with 0xff), and this works of course
well for any 'signed char' and 'unsigned char', but not for EOF.

This bug would be easy to correct, but it makes these functions less
performant and it would not work for '(char)255', because that defaults
to -1.

The gnu libc library supports this old buggy program behaviour by having
an array with 128+256 entries instead of 256+1, but I don't like that
idea for djgpp because our executables are already big enough.

I'm glad to correct it, but I need to know whether the values in range
[-128..-2] should remain supported in the case 'char' remains 'signed
char' (Mind the performance cost, please) or whether 'char' will become
'unsigned char'.

-- 
 \ Vik /-_-_-_-_-_-_/   
  \___/ Heyndrickx /          
   \ /-_-_-_-_-_-_/

- Raw text -