Re: ctype bug

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:*sigh* Which behaviour should be used instead? It can't return an error,
:because this functions are not supposed to return errors. Second, it can't
:return an arbitrary value, because that can be considered wrong too.
:Third, it can't magically cast them to unsigned, because 255 is a valid letter
:in UTF8, but also (signed)255 == EOF.

    Joerg, just because the standard says undefined doesn't give us license
    to allow an API function to randomly overflow an array and return garbage.
    It just doesn't, and we aren't going to do it.  It's totally
    inappropriate, in fact.  libc has to be more robust then that. 

:I've written about this before and the only sensible solution would be to
:switch to unsigned as default char. Anything else is WRONG.

    We are not doing this.  There is nothing wrong with having a signed char.
    There was NEVER anything wrong with having a signed char.  Chars are 
    simply 8 bit quantities.  If shorts, ints, and longs are signed, then
    why should we treat chars any differently?  I say we shouldn't, and in
    fact that it is a mistake to.  The C language was badly designed when it 
    tried to make 'char' represent an 8 bit quantity AND a character at the
    same type.  That's just the way it is, we have to live with it.  We
    cannot enforce a purist view on the world just because relatively
    recent standards have finally added types to distinguish the two.

:This problem doesn't exist since today. Actually, it was always said that you
:have to cast the argument in portable code. It's as simple as that, nothing else.

    This is a purist view.  We will never produce robust libraries and code
    using a purist view.  API functions have to be robust, and that means
    not taking an integer argument that you have no control over and then 
    blindly indexing an array with it.

:Since when do UNIX function check for arbitary violations of the interface?
:Does strcmp check for NULL pointers being passed in? No, because it should not.
:It just costs time for those who use it correctly. The same applies here.
:
:Joerg

    This is not at all equivalent and you know it.  There is obviously not
    much a C API function can do to validate a C pointer, but that does not
    give us license to then ignore passed in values that we CAN check.  The
    ctype functions are particularly fragile because many programmers
    (including me) RIGHTLY assume that passing a 'char' to a ctype function
    is a reasonable course of action, no matter what the hell the idiots
    writing the standards have written down.  The standard says its undefined,
    fine.  *I* say that the function should return a reasonable value when
    a char is passed into it.  There is no conflict.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>