Re: I don't get how the computer arrives at 2^31

In article <43b523f7$0$11073$e4fe514c@xxxxxxxxxxxxxx>, Skarmander
<invalid@xxxxxxxxxxxxxx> writes
>To be precise, an implementation could change representations as it
>sees fit, as long as it makes sure that the view to the program is
>consistent (e.g. when the value is read through an unsigned char*; it
>could normalize the representation whenever this happens). I doubt this is
>what the standard implies, but it is legal nevertheless (per the "as if"
>clause), and one can come up with implementations that could make use
>of it.


IIRC, we (WG14) decided in Sydney that where a value has multiple
representations the implementation is entitled to arbitrarily change
from one representation to another. For example, if the layout of a type
includes padding, there is no requirement that that padding be the same
bits on successive reads using a pointer to unsigned char.

I think we went further and declared that an indeterminate vale was
equivalent to allowing all bit patterns to be legitimate
representations. This is important for some types of optimisation:

e.g:

int main(){
int memory[1000000];
/* processes */
}

As the array has not been initialised the implementation is free to
choose to not save the actual bit patterns when paging out the memory,
because any pattern of bits for the million units of int storage is
equally valid.

--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
.

Relevant Pages

  • Re: I dont get how the computer arrives at 2^31
    ... Francis Glassborow writes: ... an implementation could change representations as it ... > representations the implementation is entitled to arbitrarily change ... > choose to not save the actual bit patterns when paging out the memory, ...
    (comp.std.c)
  • Re: I dont get how the computer arrives at 2^31
    ... an implementation could change representations as it ... >> representations the implementation is entitled to arbitrarily change ... >> includes padding, there is no requirement that that padding be the same ... >> bits on successive reads using a pointer to unsigned char. ...
    (comp.std.c)
  • Re: Behavior of the code
    ... Dan Henry wrote: ... representations: c0 and c0 hold bits ... conversion to the returned value. ... unsigned int) the return expression would yield the unsigned *value* ...
    (comp.lang.c)
  • Re: Integer Promotion?
    ... represented by an int, ... What if a signed short had 56 value bits and no padding bits, and a signed int had 48 value bits and 8 padding bits? ... But IMHO programmers do themselves ... in floating-point representations; they are usually content to let ...
    (comp.lang.c)
  • Re: Bit Padding and other questions
    ... So if an int has padding bits, ... Not quite -- that's two different object representations for the same ... family functions read is returned casted to (unsigned char)? ...
    (comp.lang.c)