RE: signed vs unsigned pointer warning

["Dave Korn" <dk@artimi.com>]

> -----Original Message-----
> From: Morten Welinder [mailto:terra@gnome.org] 
> Sent: 22 September 2004 17:18

> 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).
> 
> [/me gathers soapbox]
> 
> I bet you have.  In fact *ALL* ctype implementations will fail.[*]
> That includes glibc 

  You've provoked me to go and refer to the standard!

http://www.opengroup.org/onlinepubs/009695399/functions/isprint.html

------------snip!------------
int isprint(int c);

The c argument is an int, the value of which the application shall ensure is
a character representable as an unsigned char or equal to the value of the
macro EOF. If the argument has any other value, the behavior is undefined.
------------snip!------------

> It does not work for (signed char)-1 if EOF==-1.  It cannot 
> work as two
> different results are required for the same argument value.

  Um... but the ctype argument is an integer.  If you pass EOF, you get
(int)-1 in the ctype function.  If you want to pass (signed char)-1, you
have to ensure that -1 is "a character representable as an unsigned char"
first.  Which I don't think you can, since you can't store negative numbers
in an unsigned type.  So AFAICS, the valid range of inputs to the function
is the closed range [-1,255] in integers.

> What glibc does is to *mostly* work around buggy programs that send
> (explicitly or implicitly) signed characters to, say, 
> isprint.  

  The bug really is in passing a char to a function that requires an int
argument and mismanaging the promotion by not explicitly casting the char
first, isn't it?

> Solaris does the array[arg] thing you speak about.  It isn't 
> buggy.  The caller is, and, IMHO the standard is.

  As I said, I think the standard makes it quite clear that you can pass -1
and any unsigned char (0....255) value.  It seems to me to say quite clearly
that if you have a signed char variable which is negative and you pass it to
the ctype function and allow it to be sign-extended by the implicit argument
promotion rules then you have supplied an out-of-range value to the
function.

  Anyway, I only gave this particular example as an illustration to back up
my argument that the incompatibility between signed and unsigned chars is
not theoretical but very very real and does very much occur in practice as
it is very very common for char-sized arguments to be promoted to int sized
and the two types behave significantly differently when this happens.
That's all.


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....