X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f
Date: Sun, 3 Mar 2002 13:36:50 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: djgpp-workers AT delorie DOT com
Subject: Re: gcc 3.03 and libc sources
In-Reply-To: <200203022148.WAA05398@father.ludd.luth.se>
Message-ID: <Pine.SUN.3.91.1020303133627.705H-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


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.