Mail Archives: djgpp-workers/2002/03/03/07:34:51
On Sat, 2 Mar 2002, Martin Str|mberg wrote:
> According to Eli Zaretskii:
> > > From: Martin Str|mberg <ams AT ludd DOT luth DOT se>
> > > Date: Sat, 2 Mar 2002 17:41:05 +0100 (MET)
> > >
> > > if (!check_talloc(found_si ?
> > > - type->stubinfo->struct_length : 0
> > > + (unsigned int)(type->stubinfo->struct_length) : 0
> > > + (argc+1)*sizeof(short)))
> > > {
> > > argv[0] = save_argv0;
> >
> > What is the problem here, exactly? Does GCC handle zero as an
> > unsigned constant or something?
>
> No. We have type->stubinfo->struct_length as signed. 0 +
> (argc+1)*sizeof(short) is unsigned (assumption). Probably because of
> sizeof().
Ah, yes; I missed that.
> > I still think it's a bug. The normal C promotion rules for integral
> > types should take care of the different types.
>
> Yes, in a similar way promotion rules would take care of if(
> signed_value < unsigned_value ).
You are kidding, right? The promotion does work in comparison, but
the warning is justified because the comparison might yield something
that the programmer doesn't expect. By contrast, there's no such
danger in ?: expressions. In other words, if the following doesn't
trigger any warnings:
int foo;
unsigned bar;
foo = bar;
then neither should a ?: expression which has different types on the
two sides of the `:' token. If the _condition_ compared different
types before the `?', then I'd understand the warning.
It's possible that GCC confuses the parts of the expression, and looks
at types of the wrong parts.
- Raw text -