X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f
From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
To: "'Eli Zaretskii'" <eliz AT is DOT elta DOT co DOT il>
Cc: <djgpp-workers AT delorie DOT com>
Subject: Re: gcc 3.03 and libc sources
Date: Thu, 27 Dec 2001 00:45:48 +0100
Message-ID: <000701c18e67$72043aa0$cef8e0d5@zastaixp>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
In-reply-to: <3395-Wed26Dec2001222154+0200-eliz@is.elta.co.il>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
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

> > I think there's a rule in either ANSI C++ or C99 that says that
> > both values in a conditional expression (?:) need to be the exact
> > same type (including signedness).
> 
> My C9x draft only says they should be both arithmetic types.

Well, it was only related to a vague recollection.  IIRC, I ran into
this with code that used ?: to decide between cout and a file stream.
gcc complained there too (even though I was assigning to an ostream&,
so they could/should have both been seen as ostreams).

In any case, this is the code that decides to emit the warning:

[c-typeck.c, around line 3525]
      /* If -Wsign-compare, warn here if type1 and type2 have
	 different signedness.  We'll promote the signed to unsigned
	 and later code won't know it used to be different.
	 Do this check on the original types, so that explicit casts
	 will be considered, but default promotions won't.  */
      if ((warn_sign_compare < 0 ? extra_warnings : warn_sign_compare)
	  && !skip_evaluation)
	{
	  int unsigned_op1 = TREE_UNSIGNED (TREE_TYPE (orig_op1));
	  int unsigned_op2 = TREE_UNSIGNED (TREE_TYPE (orig_op2));

	  if (unsigned_op1 ^ unsigned_op2)
	    {
	      /* Do not warn if the result type is signed, since the
		 signed type will only be chosen if it can represent
		 all the values of the unsigned type.  */
	      if (! TREE_UNSIGNED (result_type))
		/* OK */;
	      /* Do not warn if the signed quantity is an unsuffixed
		 integer literal (or some static constant expression
		 involving such literals) and it is non-negative.  */
	      else if ((unsigned_op2 && tree_expr_nonnegative_p (op1))
		       || (unsigned_op1 && tree_expr_nonnegative_p
(op2)))
		/* OK */;
	      else
		warning ("signed and unsigned type in conditional
expression");
	    }
	}

This looks more like an extension to the regular signed/unsigned
comparison warning, and this is perhaps not needed.
The only potential issue seems to be that the promotions involved may
turn the return type into something that might be undesirable.