Re: its a bug - right

[Greg Chicares]

roger wrote:
> 
> address@hidden (Greg Chicares) wrote in
> >
> >What behavior do you expect? I think it's like this:
> >  strlen returns size_t, an unsigned int

[Maurizio Loreti fixed an error here (thanks)]
> >   strlen returns size_t, an unsigned int
>                            ^^^^^^^^^^^^^^^ <- an unsigned arithmetic
>                                               type

> >  so bufsize (an int) plus strlen is unsigned
> >  so -1 has to be converted to unsigned
> >  and that's a surprise in many cases, so you get a warning
> 
> Can you explain why -1 has to be converted to unsigned?

The line of code under discussion is

       int j = bufsize ? -1 : bufsize -      strlen(buf);

The second and third operands of operator ?: are of
different arithmetic types, so the value of the expression

       bufsize ? -1 : bufsize -      strlen(buf);

is determined as though the usual arithmetic conversions
were applied to these two types: 6.5.15/5 in the committee
draft of the latest C standard; 5.16 in the C++ standard.

Now size_t can be any unsigned type wide enough to hold
a value of at least 65536, but I'm guessing it's either
unsigned int or unsigned long int in the implementation
you're using. In either case, unsigned wins over signed;
there's some interesting discussion here:
  http://groups.google.com/groups?ic=1&th=56322790666c1e1f,9

> It seems reasonable that both sides of the conditional
> should be expected to yeild the same type,

Right. Otherwise the type of

       bufsize ? -1 : bufsize -      strlen(buf);

would depend on the value of 'bufsize'.

> and further, that
> this should match (or be assignable to) the type of the
> lvalue being assigned, which in this case is an int,
> not an unsigned int.

Well, 'a?b:c' is an expression that has a type already.
The type of that expression isn't affected by the type of
a variable you assign it to; rather, the value of that
expression is converted, if necessary, when the assignment
takes place.

> Are the rules different for C++ vs C in this regard?

I think K&R2 section 2.11 is saying the same thing.

> If not why doesn't gcc give the same warning?

It will if you specify '-Wconversion'. As you point out,
the warning appears in a C++ compile even if you don't
specify that flag; I don't know why the behavior differs
this way between C and C++ compiles.

> The sun C++ compiler doesn't warn about this construct either.

The construct conforms to the standard, so no warning
is required. I can't get the borland compiler to give a
warning here. Comeau says

  "6868.c", line 6: warning:
     integer conversion resulted in a change of sign
         int j = bufsize ? -1 : bufsize -      strlen(buf);

in C++, C99, or C89/90 mode.

> If anything, it seems to me that  the compiler should warn
> that the potential unsigned result of the strlen
> term does not match the type to which it is being assigned.
> But it doesn't.  Nor does it warn if say
>    int x = strlen(foo);
> so maybe I'm way off base on all of this...

I think code like that is so common that a warning would
be seen as a nuisance. Converting '-1' to unsigned is
more likely to be a mistake.