Re: Implementation-defined null pointer constant?

Wojtek Lerch wrote:
> <kuyper@xxxxxxxxxx> wrote in message
> news:1127501349.649864.80450@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> > Wojtek Lerch wrote:
....
> > I think it's sufficient to document how the bit pattern of the pointer
> > corresponds to memory locations on the machine. They don't have to
> > document how the the location of any particular object is actually
> > determined. I can't cite any relevant text to support that
> > interpretation.
>
> If this mapping between pointer representations and machine memory locations
> is what "encoding" refers to, then the relevant text has already been cited
> here. The encoding is implementation-defined (6.2.6.1 p2); most of the rest
> is unspecified (6.2.6.1 p1).

Yes, I know of that they're required to document the encoding. What I
couldn't figure out is what text to cite to support my claim that
documentating the encoding doesn't require documenting how the location
of specific objects is actually determined. It seems pretty clear to me
that the encoding that must be documented is the map from bit patterns
to memory locations, not the map from bit patters to the location of
specific objects. But what text actually says that clearly?

....
> >> ... What do they mean by "order" of the bytes -- isn't it obvious
> >> that the first byte comes first, then the second, and so on?...
> >
> > By the order of the bytes, they mean how the bytes are ordered,
> > compared with the value of the bits they contain. Most (all?) real
> > platforms group bits together in the same byte by their value, but the
> > relative order of the bits in different bytes is far less consistent.
>
> The representation of an integer type is given by a mapping of its value
> bits to the bits of its bytes and, if the type is signed, the location of
> the sign bit; when you have that mapping, there's no reason to specify an
> additional order of the bytes. Yes, most common mappings happen to map
> adjacent bits in each byte to adjacent value bits in the represented type;
> if you know that a mapping has that property and no padding bits, *then* all
> that remains to be specified is the order of bytes. Or, instead, you can
> simply refer to the mapping using a well-known short name such as "little
> endian" and "big endian". But in general, requiring that you must always
> specify the order of bytes is not meaningful. If two of the bytes contain
> nothing but padding bits, what does it mean for them to be ordered one way
> rather than the other relative to each other? Or relative to the other
> bytes?
>
> And, of course, talking about the order of bytes makes even less sense for a
> non-integer type.

I agree, I don't believe that the standard is intended to limit
implementations to encodings for which the concept of byte ordering is
a meaningful concept; therefore, requiring that an implementation
always document the byte ordering was not a good idea.

.

Relevant Pages