Re: ctype bug

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:On Wed, Jul 06, 2005 at 10:48:38AM -0700, Matthew Dillon wrote:
:>     No, that isn't a bug in the test case.  It is perfectly valid to pass
:>     a char to an is*() function.  It does NOT have to be unsigned, and
:>     the is*() function is expected to return the correct result.
:
:No, it is not. It ALWAYS was invalid, just that the old code was catching
:it in the slow path and hacking around it.
:
:>     We have to fix the is*() functions, plain and simple.
:> 
:>     EOF ?  Where'd EOF come from?  EOF is not a valid character.  It's the
:>     same as 'char c = 0xFF' and thus the is*() functions must return a
:>     representation for 0xFF in that case.
:
:It is. Please read the man page or SUS.
:
:>     The is*() functions MUST properly fold signed chars to return the correct
:>     result.  There is no two ways about it.  It MUST work, period.
:
:It can't.
:
:Joerg

    It's broken.  First, there is no way we are going to have ctype functions
    which can access random memory if passed an out of bounds integer value. 
    We are NOT writing API functions that do that, period.  Just because
    the standard says the behavior is undefined doesn't mean we go and
    let the program crash or do weird, ridiculous, stupid things.

    Secondly, the standard isn't even close to being clear about how to
    deal with char's passed into the functions.  It simply says that it be 
    representable as an unsigned char, which a signed char is simply by
    casting it to an unsigned char.

    In this, 'undefined' means we deal with signed chars properly.

    I am not going to cast the argument to an unsigned char, but I am going
    to change the macros to work the same way they work in FreeBSD, which
    is to say it will test whether the passed value is in the proper range
    rather then blindly indexing into an array.
     
					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>