Can somebody explain why the access to members of a union is "undefined" except for the most recently written member?
What can be undefined in a union of data types of the same typesize end alignment?
Can somebody explain why the access to members of a union is "undefined" except for the most recently written member?
What can be undefined in a union of data types of the same typesize end alignment? Any member written will result in a unique bit/byte pattern
in memory, whose reading may not make sense in a different type but undoubtedly is well defined.
Can somebody explain why the access to members of a union is "undefined" except for the most recently written member?
What can be undefined in a union of data types of the same typesize end alignment? Any member written will result in a unique bit/byte pattern
in memory, whose reading may not make sense in a different type but undoubtedly is well defined.
DoDi
[I think it's undefined in a standards sense. In any individual implementation the result is predictable, but it's not portable. -John]
In C, type-punning via unions is allowed (i.e., fully defined behaviour
in the standards), but not in C++ where the language is expected to
enforce higher-level aspects of the data.
David,
In C, type-punning via unions is allowed (i.e., fully defined behaviour
That is not true. Writing into one member and then reading from
another member is undefined behavior.
There is a special dispensation for what is known as a
common initial sequence:
sentence 1029
http://c0x.shape-of-code.com/6.5.2.3.html
in the standards), but not in C++ where the language is expected to
enforce higher-level aspects of the data.
This is a meaningless statement.
In C, type-punning via unions is allowed (i.e., fully defined behaviour
That is not true. Writing into one member and then reading from
another member is undefined behavior.
No, it is correct. It would be helpful if you looked at the full
"""
If the member used to read the contents of a union object is not the
same as the member last used to store a value in the object, the
appropriate part of the object representation of the value is
reinterpreted as an object representation in the new type as described
in 6.2.6 (a process sometimes called "type punning"). This might be a
trap representation.
"""
These quotations are from C18 (draft N2346), which is the current C
standard (until C23 is finalised). They have not changed since C99,
On 28/11/2021 13:51, Derek Jones wrote:
David,
In C, type-punning via unions is allowed (i.e., fully defined behaviour
That is not true. Writing into one member and then reading from
another member is undefined behavior.
No, it is correct. It would be helpful if you looked at the full
published standards, or (as most people do, since they are free) the
final pre-publishing drafts. In particular, they contain the footnotes
that appear to be missing in the format you linked here. Footnotes are
not part of the normative text, but are added for clarification.
These quotations are from C18 (draft N2346), which is the current C
standard (until C23 is finalised). They have not changed since C99,
when the footnote was added without a change to the normative text.
This means that as far as the C committee was concerned, using unions
for type-punning has always (since standardisation) been valid in C,
they realised that the text was unclear and thus added the footnote. (Arguably, since C90 did not clearly state that type-punning was
defined, the behaviour was in fact undefined - though probably all C compilers allowed the behaviour.)
David,
In C, type-punning via unions is allowed (i.e., fully defined behaviour >>>That is not true. Writing into one member and then reading from
another member is undefined behavior.
No, it is correct. It would be helpful if you looked at the full
You have misunderstood the C conformance model, which revolves around
the use of "shall" and "shall not", and the kind of section in which
they appear (e.g., Constraints). See:
http://c0x.shape-of-code.com/4..html
For a longer discussion see: http://knosof.co.uk/cbook/
On 2021-11-28, David Brown <david.brown@hesbynett.no> wrote:
On 28/11/2021 13:51, Derek Jones wrote:
David,
In C, type-punning via unions is allowed (i.e., fully defined behaviour >>>That is not true. Writing into one member and then reading from
another member is undefined behavior.
No, it is correct. It would be helpful if you looked at the full
published standards, or (as most people do, since they are free) the
final pre-publishing drafts. In particular, they contain the footnotes
that appear to be missing in the format you linked here. Footnotes are
not part of the normative text, but are added for clarification.
Not being normative means that anything that looks like a requirement
that is in a footnote is not actually a requirement.
Footnotes can only clarify requirements that are not themselves in a
foonote; they can't add new requirements.
If you cannot infer the existence of a requirement while ignoring all foonotes and examples, it isn't there.
These quotations are from C18 (draft N2346), which is the current C
standard (until C23 is finalised). They have not changed since C99,
when the footnote was added without a change to the normative text.
I have a copy of C99 (the final thing from ANSI, not a draft); I do not
see any such footnote; the paragraph has no footnotes.
I was not aware of your qualifications when I posted earlier - you have
been directly involved in things that I can only infer from reading the standards and other material.
Let me put it this way. Those of us who read the C standards, but were
not involved in writing them, do our best to interpret the precise
meaning of the words in the normative text. Those meanings are not
always clear.
David,
I was not aware of your qualifications when I posted earlier - you have
been directly involved in things that I can only infer from reading the
standards and other material.
You should always infer meaning by reading from the standard, never
defer to anybody arguing from authority.
Let me put it this way. Those of us who read the C standards, but were
not involved in writing them, do our best to interpret the precise
meaning of the words in the normative text. Those meanings are not
always clear.
You have made the mistake of reading the standard as "plain English".
Almost everybody falls into this trap when they start out.
In fact the standard is a stylized version of English, with some phrases specified to have a given meaning in specific contexts.
As the committee is always saying, the standard is not intended as
a tutorial. You probably need to read it three or four times to
get an idea of how it fits together (there is a strange logic to it).
Start by understanding how the text is styled.
The Conformance section specifies how "shall" and "shall not" are to be interpreted.
You also need to understand "unspecified behaviors" and "undefined behaviors".
See Kaz Kylheku's discussion of the status of footnotes.
You need to trace a legalistic top down approach (which takes
practice).
There are people actively discussing standard C on comp.std.c
Footnotes state the obvious when it is not obvious to somebody.
They are also an enormous source of confusion and best ignored.
You have made the mistake of reading the standard as "plain English".
Almost everybody falls into this trap when they start out.
In fact the standard is a stylized version of English, with some phrases >specified to have a given meaning in specific contexts.
As the committee is always saying, the standard is not intended as
a tutorial. You probably need to read it three or four times to
get an idea of how it fits together (there is a strange logic to it).
Start by understanding how the text is styled.
The Conformance section specifies how "shall" and "shall not" are to be >interpreted.
You also need to understand "unspecified behaviors" and "undefined behaviors".
See Kaz Kylheku's discussion of the status of footnotes.
You need to trace a legalistic top down approach (which takes practice).
There are people actively discussing standard C on comp.std.c
Footnotes state the obvious when it is not obvious to somebody.
They are also an enormous source of confusion and best ignored.
The Conformance section specifies how "shall" and "shall not" are to be
interpreted.
But it does NOT define "will" and "will not", and "must" and "must
not", and "does" and "does not" ... terms which are used liberally in
the documents, apparently without having any normative definition.
Not to mention that the Conformance section generally is not included
in draft documents. Nor are there easy to find, freely available,
references on how to read various standards documents.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 293 |
Nodes: | 16 (2 / 14) |
Uptime: | 238:31:43 |
Calls: | 6,624 |
Files: | 12,172 |
Messages: | 5,319,942 |