Skip to Content.
Sympa Menu

freetds - RE: [freetds] casts and warnings

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] casts and warnings
  • Date: Thu, 10 Mar 2005 13:18:25 +0100

>
> 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




Archive powered by MHonArc 2.6.24.

Top of Page