🚀 go-pugleaf

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?