🚀 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

Stephen Baynes wrote:
> 
> 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

Correct.

, let
> us assume it means conforming.

Bad choice. The term "conforming", when applied to user code (not to
implementations) is virtually meaningless. The U.S. Constitution is a
conforming piece of C code, or at least could be, given the existence of
a hypothetical compiler which makes it so.

I suspect the intended characteristic here is one that has been
informally dubbed "strongly conforming", meaning it violates no syntax
rule or semantic constraint, and does not invoke undefined behavior.

> 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?

Well, my vote is for implementation-defined, or at worst, unspecified,
but I can be convinced otherwise. Ints and unsigned-ints are required to
be the same size, I believe, and so the  result should depend only on
the interpretation of the UINT_MAX bit pattern as a signed int.

My gut feeling is that there's no reason why a reasonable implementation
should crash from the above code.

--

Chris Volpe				Phone: (518) 387-7766 (Dial Comm 8*833
GE Corporate R&D			Fax:   (518) 387-6560
PO Box 8, Schenectady, NY 12301		Email: volpecr@crd.ge.com

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

Norman Diamond (diamond@tbj.dec.com) wrote:
: In article <4kj9gn$6rm@engnews1.Eng.Sun.COM>, clamage@Eng.Sun.COM (Steve Clamage) writes:
   [Note - Steve Clamage's follow up has not made it to my site - was it on a
    restricted distribution, or just lost on the way?]
: >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.

Here is another reason why I think it is undefined. If there are holes
in the integers used by the implementation, there is nothing to say that
they must be in the same place in signed ints and unsigned ints. 

Also is there anything to require that the holes even have to be the same size?
In other words do signed int and unsigned int even have to use the same number
of bits for data? (It makes a bit of a mockery of the integral conversions if
they do not.) Some time ago, somewhere else I remember seeing a discusion on
implementing C on a sign-and-magnitude architecture where for unsigned numbers
used the same format as signed ones but just ignored the sign bit. This would
make UINT_MAX < INT_MAX. (Actually in this case the example problem code would
work!) This implementation was regarded as acceptable then is it now?

Just to clarify the format:
    signed int   <1 bit sign> < n bits magnatude>
  unsigned int   <1 bit hole> < n bits value>

--
Stephen Baynes                              baynes@ukpsshp1.serigate.philips.nl
Philips Semiconductors Ltd
Southampton                                 My views are my own.
United Kingdom
 Are you using ISO8859-1? Do you see © as copyright, ÷ as division and ½ as 1/2?

In article <Dpw78E.3GE@ukpsshp1.serigate.philips.nl>,
baynes@ukpsshp1.serigate.philips.nl (Stephen Baynes) wrote:

Discussing the code:

>: >>  #include <stdio.h>
>: >>  #include <limits.h>
>: >>  int main( void )
>: >>  {
>: >>      printf( "%d", UINT_MAX );
>: >>      return 0;
>: >>  }

[Discussion deleted]

>Here is another reason why I think it is undefined. If there are holes
>in the integers used by the implementation, there is nothing to say that
>they must be in the same place in signed ints and unsigned ints. 

Classic ANSI C section 3.1.2.5 says "the range of nonnegative values
of a signed integer type is a subrange of the corresponding unsigned
integer type, and the representation of the same value in each type is
the same."

The same-representation clause seems to require that significant bits
of a common value in one representation not match holes in the other.

>Also is there anything to require that the holes even have to be the same size?
>In other words do signed int and unsigned int even have to use the same number
>of bits for data? 

No, but UINT_MAX >= INT_MAX.

(It makes a bit of a mockery of the integral conversions if
>they do not.) Some time ago, somewhere else I remember seeing a discusion on
>implementing C on a sign-and-magnitude architecture where for unsigned numbers
>used the same format as signed ones but just ignored the sign bit. This would
>make UINT_MAX < INT_MAX. 

Actually the example would make UINT_MAX == INT_MAX.

Concerning sign-and-magnitude representation for ints, that format
seems to not meet the strict definition of "pure binary numeration
system" given in ANSI Classic footnote 18, because the bits of 0 and 1
are multiplied by NEGATIVE successive integral powers of 2 (the
footnote doesn't seem to allow the negative possibility for data bits,
except for the most significant bit).  Since footnotes are not part of
the standard, however, I suppose we are free to accept other
interpretations of a "pure binary numeration system".  

Thad