Re: Endianness of padded scalar objects
"Igor Tandetnik" wrote:
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-fstrict_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
.
Thanks Igor,
I think I'm finally beginning to see the light on some of the things you
have been saying. I did not consider the various optimizations and
intermediate operations that might be performed that would render "old"
members invalid.
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.
I was basing my assertion on the fact that positive integral values must use
a pure binary representation for their values (6.2.6.2p1). Then, by
definition, doesn't the least significant bit have to be a 1 to represent a
value of 1? And if there happens to be padding bits, then I suppose that
such a bit could occupy the "farthest right" bit position. But that bit
would then not be called the least significant bit would it? Or I suppose
that in some screwed up implementation the value order of the value bits
would not necessarily be the physical order of the bits in the object, but
isn't the least significant bit still going to be a 1 no matter what physical
position it occupies? Is this what you are questioning? The concept of
padding bits does bring up another question that I thought I understood,
however: If an unsigned integral object is set to a value of 1, then the
value of the object is repeatedly shifted left by 1 until its value becomes
0, I always assumed that this was a portable way to determine the number of
value bits in the data type of that object. Now I'm beginning to wonder if
the padding bits might also get included in the count. If this is the case,
however, it seems to do away with the ability to do efficient
multiplications/divisions by powers of 2 by merely shifting instead.
Thanks for your detailed explanations,
Ray