🚀 go-pugleaf

In article <4kj9gn$6rm@engnews1.Eng.Sun.COM>, clamage@Eng.Sun.COM (Steve Clamage) writes:
>In article 4Kq@ukpsshp1.serigate.philips.nl, baynes@ukpsshp1.serigate.philips.nl (Stephen Baynes) writes:
>>Is this program [conforming to all possible conforming implementations]
>>or is it going to give undefined behaviour?
>>  #include <stdio.h>
>>  #include <limits.h>
>>  int main( void )
>>  {
>>      printf( "%d", UINT_MAX );
>>      return 0;
>>  }
>>My vote is for undefined, but can anyone construct an argument based on
>>the represention of integers that makes it implmentation defined?

>The example passes an unsigned int to printf and tells printf to
>interpret the value as a signed int.

Exactly.  It does not say to convert the unsigned int.  Actually, not
quite exactly.  Although an implementation storing type tags would be
contrary to the traditional spirit of C, it would not violate the
standard.  The example tells such an implementation to check whether
the standard's rules gave the expression UINT_MAX the type int.

>The Standard's section on types says that signed int and unsigned int
>have the same size (including sign information) and alignment, and a
>footnote clarifies the intention to allow interchangeability as
>function parameters and return values.

Exactly.  The standard makes some rules that don't really accomplish
much but which provide encouragement for implementations to provide some
nice extensions.  The footnote clarifies that the committee's intention
was to encourage implementations to provide some nice extensions.  And
if I'm not mistaken, the committee already responded to a defect report
by reaffirming that their intention was to encourage implementations to
provide some nice extensions, but that implementations are not forced to
provide this interchangeability.

>The section on conversions says the result of converting an unsigned int
>to a signed int is implementation-defined if the value of the unsigned
>int is not representable as a signed int.

Exactly.  It does not say anything about the result of type punning
without conversion.

>The example has no undefined behavior, but it does have implementation-
>defined behavior.

Obviously I disagree.  The example has undefined behavior, but can have
implementation defined behavior by implementation extension.

>Pragmatically, most popular machines are straight 2's complement with no
>overflow checking,

Pragmatically, yes.

>so you will probably get the same result across a
>variety of compilers and platforms.

Pragmatically, no.  As incompetent as the original advertiser was, their
intention was clear:  they thought the result would depend on word length.
--
 <<  If this were the company's opinion, I would not be allowed to post it.  >>
"I paid money for this car, I pay taxes for vehicle registration and a driver's
license, so I can drive in any lane I want, and no innocent victim gets to call
the cops just 'cause the lane's not goin' the same direction as me" - J Spammer