🚀 go-pugleaf

In article 4Kq@ukpsshp1.serigate.philips.nl, baynes@ukpsshp1.serigate.philips.nl (Stephen Baynes) writes:
>In a glossy newsletter from a company (who had better remain nameless) that 
>sells tools for testing and validating C code the following bit of code was
>given as an example of implementation dependent but portable code across ISO 
>C implementations. I know 'portable' is not a term used in the standard, let
>us assume it means conforming. Is this program conforming, giving an 
>implementation defined result (regardless of the fact the result is probably
>not the one intended) 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.

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.

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.

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

I don't know what the assertion about portability means, either. The code
should compile and run on any system, but need not yield the same result.
I wouldn't call that portable, but to some people "portable" means "compiles
without error messages".

Pragmatically, most popular machines are straight 2's complement with no
overflow checking, so you will probably get the same result across a
variety of compilers and platforms. Maybe that's what "portable" means:
"I get the same result on the systems I currently use."
---
Steve Clamage, stephen.clamage@eng.sun.com