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