signed vs unsigned pointer warning
Paul Koning
pkoning@equallogic.com
Wed Sep 22 17:17:00 GMT 2004
>>>>> "Morten" == Morten Welinder <terra@gnome.org> writes:
Morten> Dave Korn writes:
>> Until you try indexing an array with an 8-bit high ASCII char, of
>> course. Then things become radically different. I've known buggy
>> ctype implementations that have failed on this (ASCII > 127 being
>> signed negative and the ctype function accidentally indexing
>> memory space before an array full of ctype result flags).
Morten> [/me gathers soapbox]
Morten> I bet you have. In fact *ALL* ctype implementations will
Morten> fail.[*] That includes glibc
(moved)
Morten> [*] Assuming (char)EOF==EOF, which it will be with signed
Morten> characters and EOF==-1.
EOF isn't a character.
Morten> What glibc does is to *mostly* work around buggy programs
Morten> that send (explicitly or implicitly) signed characters to,
Morten> say, isprint. It does not always work, though, so glibc
Morten> really did you a disservice. It is really hard to get people
Morten> to fix their programs.
I don't understand your point. isprint takes a char * argument. Its
semantics don't depend on whether char is signed or unsigned. It's
the job of the libc implementer to implement it correctly. It's
perfectly trivial to do that. You can do it by casts, by configure,
or by using a 384 entry array, to mention just a few.
paul
More information about the Gcc
mailing list