Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.compilers > #2764
| Path | csiph.com!weretis.net!feeder6.news.weretis.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end |
|---|---|
| From | David Brown <david.brown@hesbynett.no> |
| Newsgroups | comp.compilers |
| Subject | Re: Union C++ standard |
| Date | Tue, 30 Nov 2021 23:24:07 +0100 |
| Organization | A noiseless patient Spider |
| Lines | 112 |
| Sender | news@iecc.com |
| Approved | comp.compilers@iecc.com |
| Message-ID | <21-11-017@comp.compilers> (permalink) |
| References | <21-11-004@comp.compilers> <21-11-008@comp.compilers> <21-11-009@comp.compilers> <21-11-010@comp.compilers> <21-11-011@comp.compilers> <21-11-013@comp.compilers> <21-11-015@comp.compilers> |
| Mime-Version | 1.0 |
| Content-Type | text/plain; charset=utf-8 |
| Content-Transfer-Encoding | 8bit |
| Injection-Info | gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="36342"; mail-complaints-to="abuse@iecc.com" |
| Keywords | C, standards |
| Posted-Date | 30 Nov 2021 18:54:47 EST |
| X-submission-address | compilers@iecc.com |
| X-moderator-address | compilers-request@iecc.com |
| X-FAQ-and-archives | http://compilers.iecc.com |
| In-Reply-To | <21-11-015@comp.compilers> |
| Content-Language | en-GB |
| Xref | csiph.com comp.compilers:2764 |
Show key headers only | View raw
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
Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar
Union C++ standard Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2021-11-25 11:11 +0100
Re: Union C++ standard Kaz Kylheku <480-992-1380@kylheku.com> - 2021-11-26 18:06 +0000
Re: Union C++ standard gah4 <gah4@u.washington.edu> - 2021-11-26 12:16 -0800
Re: Union C++ standard David Brown <david.brown@hesbynett.no> - 2021-11-27 16:59 +0100
Re: Union C++ standard Derek Jones <derek@NOSPAM-knosof.co.uk> - 2021-11-28 12:51 +0000
Re: Union C++ standard David Brown <david.brown@hesbynett.no> - 2021-11-28 19:00 +0100
Re: Union C++ standard Derek Jones <derek@NOSPAM-knosof.co.uk> - 2021-11-29 00:09 +0000
Re: Union C++ standard David Brown <david.brown@hesbynett.no> - 2021-11-29 21:00 +0100
Re: Union C++ standard Derek Jones <derek@NOSPAM-knosof.co.uk> - 2021-11-30 00:46 +0000
Re: Union C++ standard George Neuner <gneuner2@comcast.net> - 2021-11-30 17:18 -0500
Re: Union C++ standard terminology Derek Jones <derek@knosof.co.uk> - 2021-12-01 13:35 +0000
Re: Union C++ standard David Brown <david.brown@hesbynett.no> - 2021-11-30 23:24 +0100
Re: Union C++ standard Kaz Kylheku <480-992-1380@kylheku.com> - 2021-11-29 16:39 +0000
Re: Union C++ standard Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-11-29 14:32 -0800
csiph-web