🚀 go-pugleaf

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