FreeTDS Development Group

["ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>]

> 
> On Mar 9,  7:21pm, jklowden AT schemamania.org ("James K. Lowden") wrote:
> -- Subject: Re: [freetds] casts and warnings
> 
> | (I would love to know what compiler issued what warning.  I 
> doubt the
> | compiler knew about isspace(3)'s peculiar unsigned char 
> restriction.)  
> 
> You have to look at the implementation.
> If it is implemented as:
> #define isspace(c) (__ctype[c] & _S)
> 
> gcc will produce a warning because you are indexing an array 
> with a char.
> 
> | As I read it, the programmer is obliged to ensure 0 <= c <= 
> 255.  Casting
> | a negative value to unsigned char achieves that in only the 
> narrowest of
> | technical senses.  0xff == 0xff, but -1 != 255.  Redefining the bits
> | doesn't guard against bad inputs; it merely treats a bad input as
> | something it's not.  
> | 
> | To do what you want, we'd do something like this:
> | 
> |     for (p+=2; *p >= 0 && isspace(*p); p++) {
> |     ...
> |     }
> |     if (*p < 0) {
> |             /* log error */
> |             return 0; /* or whatever */
> |     }
> | 
> | I think that's overkill, and I think every isspace(3) 
> implementation will
> | return zero for any negative value in every locale.  But at 
> least we're
> | not  pretending:
> | 
> |      (unsigned char) *p == 128 + (0x7F & *p)
> | 
> | As far as C is concerned, I assume we agree that as long as *p is
> | nonnegative, no cast is needed or desired to promote char to int.  
> 
> Casting to unsigned char is the proper way to fix the problem.
> There are charsets that have valid characters > 127 and the cast
> makes them work.
> 

Happily gcc under HP-UX give me this warning. Perhaps a better way is to
define a macro like TDS_ISSPACE (already defined in some C file) to
handle this case. This can cause a buffer reading underflow with
undefined behavior (core or bad results). If I remember under Linux the
"array" is defined from -128 to 255 to handle signed chars correctly.

freddy77