[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: its a bug - right
From: |
Greg Chicares |
Subject: |
Re: its a bug - right |
Date: |
Sun, 10 Jun 2001 23:29:12 -0400 |
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.