Re: I don't get how the computer arrives at 2^31
- From: Tim Rentsch <txr@xxxxxxxxxxxxxxxxxxx>
- Date: 30 Dec 2005 11:58:54 -0800
Francis Glassborow <francis@xxxxxxxxxxxxxxxxxxxx> writes:
> 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.
If so that has grave implications for the language model.
Accessing objects through unsigned char * would basically
guarantee that a program could not be strictly conforming,
for example.
Do you have a reference for any discussion that went on
around this? I did a search through wg14 documents at
the open-std.org website and didn't find anything.
> 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.
Amazing.
I'd like to offer the opinion that the interests of compiler writers
are over-represented in making these kinds of decisions.
(In any case, thank you Francis for the informative report.)
.
- Follow-Ups:
- Re: I don't get how the computer arrives at 2^31
- From: Jordan Abel
- Re: I don't get how the computer arrives at 2^31
- References:
- Re: I don't get how the computer arrives at 2^31
- From: Douglas A. Gwyn
- Re: I don't get how the computer arrives at 2^31
- From: Tim Rentsch
- Re: I don't get how the computer arrives at 2^31
- From: Skarmander
- Re: I don't get how the computer arrives at 2^31
- From: Francis Glassborow
- Re: I don't get how the computer arrives at 2^31
- Prev by Date: Re: I don't get how the computer arrives at 2^31
- Next by Date: Re: Bit field types and promotions
- Previous by thread: Re: I don't get how the computer arrives at 2^31
- Next by thread: Re: I don't get how the computer arrives at 2^31
- Index(es):
Relevant Pages
|