R
Richard Heathfield
[Not much snipping, I'm afraid - I prefer to snip when possible, but
here it seems unwise.]
Keith Thompson said:
I won't argue about C99, specifically because I couldn't find wording in
the C99 Standard to match the C89 wording (as I hinted above, although
I actually said C90 when I should have said C89 - I only have a late
C89 draft). I'm sure of my ground ifF the final C90 Standard agrees
with the C89 draft.
I won't even argue with /that/, but see below.
Sure. Hang on...
"With one exception, if a member of a union object is accessed after
a value has been stored in a different member of the object, the
behavior is implementation-defined."
That's 3.3.2.3 in C89. So no, the Standard doesn't define the behaviour,
but it requires the /implementation/ to define the behaviour, and
that's not what we normally understand by "undefined", any more than
the value of CHAR_BIT is undefined.
Nevertheless, you can still prove me wrong if you can show... well, it's
hard to show an absence, isn't it? But if you say that the C89 late
draft wording cited above is missing from the C90 spec, I'll certainly
take your word for it.
here it seems unwise.]
Keith Thompson said:
I based my statement on the following in the C99 standard:
I won't argue about C99, specifically because I couldn't find wording in
the C99 Standard to match the C89 wording (as I hinted above, although
I actually said C90 when I should have said C89 - I only have a late
C89 draft). I'm sure of my ground ifF the final C90 Standard agrees
with the C89 draft.
C99 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. A pointer to a union object, suitably
converted, points to each of its members (or if a member is a
bitfield, then to the unit in which it resides), and vice versa.
C90 6.5.2.1 has identical wording.
I infer from the second sentence that the standard does not define the
behavior of reading a union member other than the one last stored,
I won't even argue with /that/, but see below.
except:
C99 6.5.2.3p5:
Chances are that you're right, and I'm missing something. Can you
provide C&V?
Sure. Hang on...
"With one exception, if a member of a union object is accessed after
a value has been stored in a different member of the object, the
behavior is implementation-defined."
That's 3.3.2.3 in C89. So no, the Standard doesn't define the behaviour,
but it requires the /implementation/ to define the behaviour, and
that's not what we normally understand by "undefined", any more than
the value of CHAR_BIT is undefined.
Nevertheless, you can still prove me wrong if you can show... well, it's
hard to show an absence, isn't it? But if you say that the C89 late
draft wording cited above is missing from the C90 spec, I'll certainly
take your word for it.