X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f
Date: Tue, 25 Dec 2001 13:31:51 +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: <200112251052.LAA10619@father.ludd.luth.se>
Message-ID: <Pine.SUN.3.91.1011225131954.5289B-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 Tue, 25 Dec 2001, Martin Str|mberg wrote:

> -  *decpt = dot ? dot - s : strlen (s);
> +  *decpt = dot ? dot - s : (ssize_t)strlen (s);

I don't understand why did you cast to ssize_t here.  I'd say either cast 
to int or to ptrdiff_t.  The latter is more accurate, since "dot -s" is a 
difference between two pointers; but because gcc wants a signed type, int 
should be okay as well.

I still have no idea why does gcc complain here.  What's wrong about 
having an expression whose result could be either signed or unsigned?  I 
think it's worth a bug report nonetheless, if only to hear an 
explanation from the maintainers.

If this is somehow ``justified'' from their point of view, I'd suggest 
changing the code so that it no longer uses a conditional expression, but 
instead uses if..else.

>    if (!check_talloc(found_si ?
> -                   type->stubinfo->struct_length : 0
> +                   (unsigned int)(type->stubinfo->struct_length) : 0

This is really ridiculous on the part of gcc!!  Does it help to say 0U 
instead of just 0, and leave the struct_length part alone?

> -  int     name_len              = dot ? dot - mybasename : total_len;
> +  int     name_len              = dot ? dot - mybasename : (ssize_t)total_len;

Same comment as with the first hunkl above.

> > > #define ARG(basetype) _ulonglong = \
> > >                 flags&LONGDBL ? va_arg(argp, long long basetype) : \
> > >                 flags&LONGINT ? va_arg(argp, long basetype) : \
> > >                 flags&SHORTINT ? (short basetype)va_arg(argp, int) : \
> > >                 va_arg(argp, int)
> > > [...]
> > > I'm not sure what I should do to solve this.
> > 
> > Report a bug to the gcc-bug mailing list, I guess.  I don't see
> > anything wrong with the code it flags here.
> > 
> > Note that the complaints are about the calls of ARG with an unsigned
> > type as its argument, while `flags' is an int.  I don't see how could
> > that be wrong, but maybe declare `flags' unsigned and see if that
> > helps.
> 
> The problem (according to gcc) is that we have an expression like
> this, with types instead of variable:
> 
> bool ? some_type_I_am_not_sure_which_but_seems_to_be_signed : short unsigned
> 
> Note that gcc are talking about the resulting types, not the types in
> the boolean expression (I think).

Then perhaps a better solution is to modify the last part of the 
definition of ARG like this:

 #define ARG(basetype) _ulonglong = \
                 flags&LONGDBL ? va_arg(argp, long long basetype) : \
                 flags&LONGINT ? va_arg(argp, long basetype) : \
                 flags&SHORTINT ? (short basetype)va_arg(argp, int) : \
                 (basetype)va_arg(argp, int)

> So is va_arg's type signed? Or is it supposed to depend on the second
> argument?

AFAIK, its return type is identical to the type of its argument.  (This 
of course depends on how va_arg is defined, and I'm not even sure we use 
our definition: it might be the one taken from GCC headers.)