Undefined behavior in 950605-1.c

Undefined behavior in 950605-1.c

[Momchil Velikov]

IMHO, gcc.c-torture/execute/950605-1.c (pasted below) provokes
undefined behavior according to ISO 9899:1999 6.5.2.2 [#6]

       ... If the function is defined with a type that does not
       include a prototype, and the types of the arguments after
       promotion are not compatible with those of the parameters after
       promotion, the behavior is undefined, except for the following
       cases:

         -- one promoted type is a signed integer type, the other
            promoted type is the corresponding unsigned integer type,
            and the value is representable in both types;

f (c)
    unsigned char c;
{
  if (c != 0xFF)
    abort ();
}

main ()
{
  f (-1);
  exit (0);
}

IOW, the value -1 is not representable in the promoted type of the
formal parameter of ``f''.

Comments?

~velco

Re: Undefined behavior in 950605-1.c

[Andreas Schwab]

Momchil Velikov <velco@fadata.bg> writes:

|> IMHO, gcc.c-torture/execute/950605-1.c (pasted below) provokes
|> undefined behavior according to ISO 9899:1999 6.5.2.2 [#6]
|> 
|>        ... If the function is defined with a type that does not
|>        include a prototype, and the types of the arguments after
|>        promotion are not compatible with those of the parameters after
|>        promotion, the behavior is undefined, except for the following
|>        cases:
|> 
|>          -- one promoted type is a signed integer type, the other
|>             promoted type is the corresponding unsigned integer type,
|>             and the value is representable in both types;
|> 
|> f (c)
|>     unsigned char c;
|> {
|>   if (c != 0xFF)
|>     abort ();
|> }
|> 
|> main ()
|> {
|>   f (-1);
|>   exit (0);
|> }
|> 
|> IOW, the value -1 is not representable in the promoted type of the
|> formal parameter of ``f''.

The promoted type of the formal parameter of f is either int or unsigned
int, and -1 is representable in both types.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Undefined behavior in 950605-1.c

[Momchil Velikov]

>>>>> "Andreas" == Andreas Schwab <schwab@suse.de> writes:
Andreas> |> 
Andreas> |> f (c)
Andreas> |>     unsigned char c;
Andreas> |> {
Andreas> |>   if (c != 0xFF)
Andreas> |>     abort ();
Andreas> |> }
Andreas> |> 
Andreas> |> main ()
Andreas> |> {
Andreas> |>   f (-1);
Andreas> |>   exit (0);
Andreas> |> }
Andreas> |> 
Andreas> |> IOW, the value -1 is not representable in the promoted type of the
Andreas> |> formal parameter of ``f''.

Andreas> The promoted type of the formal parameter of f is either int
Andreas> or unsigned int, and -1 is representable in both types.

Hmm, what does "representable" means ? I'd think (on 32-bit two's
complement machine) [-2^31, 2^31) is representable by ``int'' and [0,
2^32) is representable by ``unsigned int'', thus -1 is not
representable if the promoted type of the parametar is unsigned.

~velco

Re: Undefined behavior in 950605-1.c

[Momchil Velikov]

>>>>> "Alan" == Alan Modra <amodra@bigpond.net.au> writes:

Alan> On Thu, Jul 25, 2002 at 12:53:59PM +0300, Momchil Velikov wrote:
>> representable if the promoted type of the parametar is unsigned.

Alan> Ah, but what is the promoted type of "unsigned char"?  int!

ISO/IEC 9899:1999 6.5.2.2 [#6]

  " ... the other promoted type is the corresponding unsigned integer
  type, ..."

IMHO, that means that it is legal for the promoted type of ``unsigned
char'' to be ``unsigned int''.  Isn't that the case with architectures
with a definition of PROMOTE_MODE, which does not change UNSIGNEDP or
sets it to 1, e.g, ARM, PPC, V850 ?

Indeed it contradicts with 6.3.1.1 [#2]:

  "If an int can represent all values of the original type, the value
  is converted to an int; otherwise, it is converted to an unsigned
  int.  These are called the integer promotions."

~velco

Re: Undefined behavior in 950605-1.c

[Andreas Schwab]

Momchil Velikov <velco@fadata.bg> writes:

|> >>>>> "Alan" == Alan Modra <amodra@bigpond.net.au> writes:
|> 
|> Alan> On Thu, Jul 25, 2002 at 12:53:59PM +0300, Momchil Velikov wrote:
|> >> representable if the promoted type of the parametar is unsigned.
|> 
|> Alan> Ah, but what is the promoted type of "unsigned char"?  int!
|> 
|> ISO/IEC 9899:1999 6.5.2.2 [#6]
|> 
|>   " ... the other promoted type is the corresponding unsigned integer
|>   type, ..."
|> 
|> IMHO, that means that it is legal for the promoted type of ``unsigned
|> char'' to be ``unsigned int''.

Only if UCHAR_MAX == UINT_MAX.  Otherwise int can represent all values of
unsigned char, thus unsigned char is promoted to int.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Undefined behavior in 950605-1.c

[Richard Henderson]

On Thu, Jul 25, 2002 at 03:22:46PM +0300, Momchil Velikov wrote:
> Alan> Ah, but what is the promoted type of "unsigned char"?  int!

Except if sizeof(char) == sizeof(int).

> Isn't that the case with architectures
> with a definition of PROMOTE_MODE, which does not change UNSIGNEDP or
> sets it to 1, e.g, ARM, PPC, V850 ?

PROMOTE_MODE has nothing to do with C types.  It's for efficiency
in the generated rtl *only*.  If a strictly conforming program can
notice the existance of PROMOTE_MODE, there is a bug.


r~

Re: Undefined behavior in 950605-1.c

[Richard Earnshaw]

> PROMOTE_MODE has nothing to do with C types.  It's for efficiency
> in the generated rtl *only*. 

I believe it can also be part of the ABI specification, so someone writing 
assembler would be able to tell the difference, and a compiler can assume 
that a caller has done the promotion (so saving a repeat promotion).

> If a strictly conforming program can
> notice the existance of PROMOTE_MODE, there is a bug.

Agreed.

R.

Re: Undefined behavior in 950605-1.c

[Richard Henderson]

On Fri, Jul 26, 2002 at 09:54:52AM +0100, Richard Earnshaw wrote:
> > PROMOTE_MODE has nothing to do with C types.  It's for efficiency
> > in the generated rtl *only*. 
> 
> I believe it can also be part of the ABI specification...

This is true.  I was sort of glossing over that to avoid confusion.


r~