Is using a structure without all members assigned undefined? - c

Question

Consider this code in block scope:
struct foo { unsigned char a; unsigned char b; } x, y;
x.a = 0;
y = x;
C [N1570] 6.3.2.1 2 says “If the lvalue designates an object of automatic storage duration that could have been declared with the register storage class (never had its address taken), and that object is uninitialized (not declared with an initializer and no assignment to it has been performed prior to use), the behavior is undefined.”
Although a member of x has been assigned a value, no assignment to x has been performed, and its address has not been taken. Thus, it appears 6.3.2.1 2 tells us the behavior of x in y = x is undefined.
However, if we had assigned a value to every member of x, it would seem unreasonable to consider x to be uninitialized for the purposes of 6.3.2.1 2.
(1) Is there anything in the standard which, strictly speaking, causes 6.3.2.1 2 not to apply to (make undefined) the code above?
(2) Supposing we were modifying the standard or determining a reasonable modification to 6.3.2.1 2, are there reasons to prefer one of the following over the others? (a) 6.3.2.1 2 does not apply to structures. (b) If at least one member of a structure has been assigned a value, the structure is not uninitialized for purposes of 6.3.2.1 2. (c) If all named1 members of a structure have been assigned a value, the structure is not uninitialized for purposes of 6.3.2.1 2.
Footnote
1 Structures may have unnamed members, so it is not always possible to assign a value to every member of a structure. (Unnamed members have indeterminate value even if the structure is initialized, per 6.7.9 9.)

Answer 1

My opinion is that it is undefined behaviour simply because it is not explicitly defined by the standard. From 4 Conformance §2 (emphasize mine) :
...Undefined behavior is otherwise
indicated in this International Standard by the words ‘‘undefined behavior’’ or by the
omission of any explicit definition of behavior.
After many reads in N1570 draft I cannot find any explicit definition of behaviour for using a partially initialized struct. On one hand 6.3.2.1 §2 says:
...If
the lvalue designates an object of automatic storage duration that could have been
declared with the register storage class (never had its address taken), and that object
is uninitialized (not declared with an initializer and no assignment to it has been
performed prior to use), the behavior is undefined
so here x is automatic, has never be initialized (only one of its members), and admitedly its address is never taken so we could think that it is explicitely UB
On the other hand, 6.2.6.1 §6 says:
... The value of a structure or union object is never a trap representation, even though the value of a member of the structure or union object may be a trap representation.
As 6.2.6.1 §5 has just defined a trap representation:
Certain object representations need not represent a value of the object type. If the stored
value of an object has such a representation and is read by an lvalue expression that does
not have character type, the behavior is undefined. If such a representation is produced
by a side effect that modifies all or any part of the object by an lvalue expression that means 0 value for a member and an undefined value for b member.
does not have character type, the behavior is undefined.50) Such a representation is called
a trap representation.
we could think that it is always legal to take the value of a struct because it cannot be a trap representation
In addition, it is not clear for me if setting the value of a member of a struct actually leaves the struct in an unitialized state.
For all those reasons, I think that the standard does not clearly defines what the behaviour should be and simply for that reason it is undefined behaviour.
That being said I am pretty sure that any common compiler will accept it and will give y the current representation of x, that means 0 value for a member and an indeterminate value of same representation as the current one for x.b for the b member.

Answer 2

Firstly, let's note that the quoted part of 6.3.2.1/2, the so-called "Itanium clause" is the only clause under which this code might have a problem. In other words, if this clause were not present, the code is fine. Structs may not have trap representations, so y = x; is otherwise OK even if x is entirely uninitialized. The resolution of DR 451 clarifies that indeterminate values may be propagated by assignment, without causing UB.
Back to the Itanium clause here. As you point out, the Standard does not clearly specify whether x.a = 0; negates the precondition "x is uninitialized".
IMO, this means we should turn to the rationale for the Itanium clause to determine the intent. The purpose of the wording of the standard document, in general, is to implement an intent; generally speaking, I don't agree with being dogmatic about minute detail of the standard: taking shades of meaning out of the wording that were not intended by those who created the wording.
This Q/A gives a good explanation of the rationale. The potential problem is that x might be stored in a register with the NaT bit set, and then y = x will cause a hardware exception due to reading a register that has that bit set.
So the question is: On IA64 does x.a = 0; clear the NaT bit? I don't know and I guess we would need someone familar with that platform to give a conclusive answer here.
Naively, I imagine that if x is in a register then, in general, x.a = 0; will need to read the old value, and apply a mask to clear the bits for a, thereby triggering the exception if x was NaT. However, x.a = 0; cannot trigger UB, so that logic must be incorrect. Perhaps IA64 compilers never store a struct in a register, or perhaps they clear the NaT bit on declaration of one, or perhaps there's a hardware instruction to implement x.a = 0; on a previously-NaT register, I don't know.

Answer 3

Copying a partially-written structure falls in the category of actions which quality implementations will process in consistent fashion absent a good reason to do otherwise, specialized implementations might process differently because they have a good reason to do so, and poor-quality-but-conforming implementations may use as an excuse to behave nonsensically.
Note that copying uninitialized values of an automatic-duration or malloc-created character array would fall in a similar category of actions, except that implementations that would trap on such an action (e.g. to help programmers identify and track down potential information leaks) would not be allowed to describe themselves as "conforming".
An implementation which is specialized to diagnose accidental information leaks might sensibly trap efforts to copy a partially-written structure. On an implementation where using an unitialized value of some type could result in strange behavior, copying a structure with an unitialized member of that type and then attempting to use that member of the copy might sensibly do likewise.
The Standard doesn't particularly say whether a partially-written structure counts as having been written or not, because people seeking to produce quality implementations shouldn't care. Quality implementations specialized for detecting potential information leakage should squawk at any attempt to copy uninitialized data, without regard for when the Standard would or would not allow such behavior (provided that they describe themselves as non-conforming). Quality general-purpose implementations designed to support a wide variety of programs should allow partially-initialized structures to be copied in cases where programs don't look at the uninitialized portions outside the context of whole-structure copying (such treatment is useful and generally costs nothing in non-contrived cases). The Standard could be construed as granting poor-quality-but-conforming implementations the right treat copying of partially-written structures as an excuse to behave nonsensically, but such implementations could use almost anything as such an excuse. Quality implementations won't do anything unusual when copying structures unless they document a good reason for doing so.

Answer 4

The C Standard specifies that structure types cannot have trap representations, although members of structs may. The primary circumstance in which that guarantee would be useful would be in cases involving partially-written structures. Further, a prohibition on copying structures before one had written all members, even ones the recipient of the copy would never use, would require programmers to write needlessly-inefficient code and serve no useful purpose. Imposing such a requirement in the name of "optimization" would be downright dumb, and I know of no evidence that the authors of the Standard intended to do so.
Unfortunately, the authors of the Standard use the same terminology to describe two situations:
Some implementations define the behavior of some action X in all cases, while some only define it for some; other parts of the Standard define the action in a few select cases. The authors want to say that implementations need not behave like the ones that define the behavior in all cases, without revoking guarantees made elsewhere in the Standard
Although other parts of the Standard would define the behavior of action X in some cases, guaranteeing the behavior in all such cases could be expensive and implementations are not required to guarantee them even cases where other parts of the Standard would define them.
Before the Standard was written, some implementations would zero-initialize all automatic variables. Thus, those implementations would guarantee the behavior of reading uninitialized values, even of types with trap representations. The authors of the Standard wished to make clear that they did not want to require all implementations do likewise. Further, some objects may define the behavior of all bit patterns when stored in memory, but not when stored in registers. Such treatment would generally be limtied to scalar types, however, rather than structures.
From a practical perspective, defining the behavior of copying a structure as copying the state (defined or indeterminate) of all fields would not cost any more than allowing compilers to behave in arbitrary fashion when copying partially-written structures. Unfortunately, some compiler writers erroneously believe that "cleverness" and "stupidity" are antonyms, and thus behave as though the authors of the Standard wished to invite compilers to assume that programs will never receive any input that would cause structures to be copied after having been partially written.