| From: | "Simon 'corecode' Schubert" <corecode@xxxxxxxxxxxx> |
| Date: | Wed, 6 Jul 2005 20:43:49 +0200 |
Lately Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx> said: > > 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. I have to second Joerg. I thought like Matt before, but after reading C99/SUS, it is clear that any program passing negative vlaues other than EOF is broken. It explicitly states that parameters must fit into an unsigned char or have the value of the macro EOF. So any program passing chars or signed chars is broken, unfortunately. I would prefer unsigned chars as default anyways... > > 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. yah, that's the way it is... basically is*() operates on the value returned by getch() (an int which fits into an unsigned char or is EOF), and not on plain chars... > > 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. I'd put it this way: it SHOULD work with 'char's, but it CAN'T on signed chars. cheers simon -- Serve - BSD +++ RENT this banner advert +++ ASCII Ribbon /"\ Work - Mac +++ space for low $$$ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \
Attachment:
pgp00009.pgp
Description: PGP signature