Re: Endianness of padded scalar objects
Ray Mitchell <RayMitchell@discussions.microsoft.com> wrote:
"Igor Tandetnik" wrote:
6.7.2.1p14 The size of a union is sufficient to contain the largest
of its members. The value of at most one of the members can be
stored in a union object at any time.
I don't agree that this makes reading a member that was not most
recently written undefined as long as the member being read shares
all of its bytes with the recently written member. Concerning the
"older" members of a union,
6.1.6.2p7 of the standard says, "When a value is stored in a member
of an object of union type, the bytes of the object representation
that do not correspond to that member but do correspond to other
members take unspecified values, but the value of the union object
shall not thereby become a trap representation."
This just says that the union shouldn't turn into something that the CPU =
would throw a hardware exception on (some architectures have bit =
patterns that cause the CPU to do so - known as "trap representations").
When the compiler
generates code to access the various union members, that code merely
accesses the appropriate bytes in the common object and interprets
them in the way appropriate to that member's data type. The code to
do this is "permanent" and does not change just because another
member was recently written.
Of course not. But the program that necessitates running this code =
exhibits undefined behavior. Consider:
int* p = malloc(sizeof(int));
*p = 1;
if (rand() % 2) {
free(p);
}
*p = 42;
Code that assigns 42 to *p doesn't change just because memory is freed. =
Nevertheless, if it was indeed freed, that line exhibits undefined =
behavior - it accesses an object whose lifetime has ended.
Instead, the access is made without any
memory of what might have happened to the object previously.
That doesn't make such access any more valid.
As a
result the values of the bytes being read are exactly the values that
were written.
Not necessarily. The compiler can legally optimize away the assignment =
to one member of the union, seeing that the member is never read =
afterwards. See also
http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Optimize-Options.html#index-f=
strict_002daliasing-542
(note that GCC doesn't perform this optimization in the simple case - =
only because there's too much invalid code in existence that would be =
broken by it). If the compiler does that, then no value is written, and =
the value read is random garbage.
6.2.4p2 The lifetime of an object is the portion of program
execution during which storage is guaranteed to be reserved for it.
An object exists, has a constant address, and retains its
last-stored value throughout its lifetime. If an object is referred
to outside of its lifetime, the behavior is undefined.
I agree totally, and the object in this case is the underlying memory
common to all members.
Not quite. The union as a whole is an object, and each union member is =
itself an object:
6.2.5p20 A union type describes an overlapping nonempty set of member =
objects, each of which has an optionally specified name and possibly =
distinct type.
Remember also 6.7.2.1p14: "The value of at most one of the members can =
be stored in a union object at any time." Thus, one member object cannot =
possibly "retain its last-stored value" when another member is assigned =
to - the union can only hold one value at a time.
C++ standard states this more explicitly:
3.8p1 ...The lifetime of an object of type T ends when: ... the storage =
which the object occupies is reused...
But this is unrelated to the issue we're
discussing since the lifetime of the object does not end between the
write and the read.
Lifetime of the union doesn't, but lifetime of the member object whose =
storage has been hijacked does.
However, this doesn't give you much, in view of aforementioned
6.2.6.1p1 - in general, you have no idea what to expect when looking
at individual bytes of an object.
But my original example was not the general case. It merely set the
value
of an integral type to a value of 1, and I believe that guarantees
that only the least significant bit will be a 1.
What is the basis for this belief? It is my turn now to demand chapter =
and verse.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not =
necessarily a good idea. It is hard to be sure where they are going to =
land, and it could be dangerous sitting under them as they fly overhead. =
-- RFC 1925