DragonFly commits List (threaded) for 2005-07
Re: ctype bug
:*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.
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.