Re: Union C++ standard

On 30/11/2021 01:46, Derek Jones wrote:
> 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.


But it helps to listen to people or read sources that have established a
position of respect and a reputation for reliability. Of course anyone
can get things wrong. If several people whom I know to be experts in a
language all agree, but have an interpretation different from what I
read in the standard, then I must suspect my own interpretation - at the
very least, it warrants further investigation and discussion.


In this case, you are - I assume - a person with a high degree of
experience and knowledge of the C standards. I don't know you well
enough to judge for myself, having only read a few of your posts, but
your qualifications are significant. Your interpretation of the
standard here differs from mine, and from how I have seen many other
experts and reliable resources interpret it. So I am not deferring to
anyone - I am reading the standard. But I am asking to help figure out
if I am reading the standard correctly!


>> 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.
>


I am not making that mistake - at least, not as a general point. I am
well aware of the specialised and stylized language used in the
standard, and how specific terms and phrases can have meanings that are
not "plain English". It is, however, possible that I am making an error
in the interpretation of this particular issue. Just as I do not know
you, you do not know me - I've been studying and discussing the C
standards for a great many years, and I am not new to it. (Again, that
experience does not mean I think I know everything about it or that my
interpretation of it is flawless.) My programming field is quite
specialised - small-systems embedded programming - and I have not
bothered about parts of the standard that are not relevant there. But
I've gone through a lot of the "meat" of the documents, many times.


> 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.
>


Yes.


> You also need to understand "unspecified behaviors" and "undefined
> behaviors".
>


I know.


> See Kaz Kylheku's discussion of the status of footnotes.
>


I did. I agree that the footnotes are not normative, but I don't agree
with his interpretation of the footnote. The footnote says very clearly
that type-punning using a union is defined as storing a value of one
type in the representation (given in 6.2.6, along with
implementation-dependent details), then re-interpreting that
representation as the new type when read.


> You need to trace a legalistic top down approach (which takes
> practice).
>
> There are people actively discussing standard C on comp.std.c
>


I follow that group.


> Footnotes state the obvious when it is not obvious to somebody.
> They are also an enormous source of confusion and best ignored.


I'm sorry, but none of what you wrote comes close to answering my
question. Your response merely says that the standard is written in
"standardese" and must be read appropriately - had I been new to the C
standards, it would have been useful.


The footnote was added specifically as a TC based on a DR that would
have been voted on, and it has been left untouched through three
revisions of the standard despite being arguably a critical part of the
language that many programs rely on. Either the footnote accurately
describes the "rules" of the language - that type-punning via unions is
defined behaviour that can be relied upon (albeit with some
implementation-specific details, and scope for undefined behaviour from
accessing trap representations - such as storing 2 to a char, then
reading it as a _Bool), or the footnote was added deliberately and
intentionally with the aim of confusing and misleading people.


I find it hard to believe the latter - despite that being your suggestion
here.


Again, if you see a flaw in my reasoning, please say.


David

Return to the comp.compilers page.
Search the comp.compilers archives again.