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 Mime-Version: 1.0 To: djgpp-workers AT delorie DOT com Subject: Re: char != unsigned char... sometimes, sigh References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk 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 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 / \ /-_-_-_-_-_-_/