Related articles |
---|
[3 earlier articles] |
Re: Union C++ standard david.brown@hesbynett.no (David Brown) (2021-11-27) |
Re: Union C++ standard derek@NOSPAM-knosof.co.uk (Derek Jones) (2021-11-28) |
Re: Union C++ standard david.brown@hesbynett.no (David Brown) (2021-11-28) |
Re: Union C++ standard derek@NOSPAM-knosof.co.uk (Derek Jones) (2021-11-29) |
Re: Union C++ standard 480-992-1380@kylheku.com (Kaz Kylheku) (2021-11-29) |
Re: Union C++ standard david.brown@hesbynett.no (David Brown) (2021-11-29) |
Re: Union C++ standard Keith.S.Thompson+u@gmail.com (Keith Thompson) (2021-11-29) |
Re: Union C++ standard derek@NOSPAM-knosof.co.uk (Derek Jones) (2021-11-30) |
Re: Union C++ standard gneuner2@comcast.net (George Neuner) (2021-11-30) |
Re: Union C++ standard david.brown@hesbynett.no (David Brown) (2021-11-30) |
From: | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
Newsgroups: | comp.compilers |
Date: | Mon, 29 Nov 2021 14:32:21 -0800 |
Organization: | None to speak of |
References: | 21-11-004 21-11-008 21-11-009 21-11-010 21-11-012 |
Injection-Info: | gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="7255"; mail-complaints-to="abuse@iecc.com" |
Keywords: | C, standards, comment |
Posted-Date: | 29 Nov 2021 18:09:01 EST |
Kaz Kylheku <480-992-1380@kylheku.com> writes:
> 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 don't think N2346 is a draft of "C18". The page headers say:
N2346 working draft — March 13, 2019 ISO/IEC 9899:202x (E)
The current C standard is usually referred to as "C17"; it's a minor
update to C11. Work is in progress on C2X, which will supersede C17.
> 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.
(It was published by ISO. ANSI adopted it and sold copies.)
The footnote does not appear in the published 1999 ISO C standard. It
was added by Technical Corrigendum 3, published in 2007 (and therefore
in the N1256 draft, which includes the 1999 standard with the three
Technical Corrigenda merged into it). As far as ISO is concerned, it's
part of C99 -- and of later editions of the standard, which have
superseded C99.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[I think this horse has been beaten about all it needs to. And
it reminds us that just because C says something is defined does
not mean it's portable or that the results are easily predictable.
This is hardly the only place, e.g., the exciting range of things
that might or might not happen if the result of an integer operation
doesn't fit in its result type. It might wrap, it might overflow,
it might saturate. Or it might not. -John]
Return to the
comp.compilers page.
Search the
comp.compilers archives again.