Path: csiph.com!news.mixmin.net!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: structs passed by copy Date: Tue, 24 Jan 2023 07:53:19 -0800 Organization: A noiseless patient Spider Lines: 70 Message-ID: <86bkmogc9c.fsf@linuxsc.com> References: <76ec6d87-0f5d-4671-b4c8-7023e3da787an@googlegroups.com> <20230120230138.1225d36e5ad8e5f07401c67a@gmail.com> <1btu0jojlm.fsf@pfeifferfamily.net> <87edrnifxn.fsf@nosuchdomain.example.com> <87sfg2gszl.fsf@nosuchdomain.example.com> <87o7qqglva.fsf@nosuchdomain.example.com> <86fsc0hl4i.fsf@linuxsc.com> <87a628g440.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader01.eternal-september.org; posting-host="c6b31012a9551ab5c55cbf393aa16f93"; logging-data="215085"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19MQEPUi7HgW+eu/DMDwhib3onAd8mku1E=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:TsO400QLCWeZQZBFFfxr3xdunjE= sha1:yXsCUOCClAMgOx4DnIvsOS9vdFA= Xref: csiph.com comp.lang.c:169004 Keith Thompson writes: > Tim Rentsch writes: > >> Keith Thompson writes: >> >> [...] >> >>> BTW, I was wrong about one thing: Support for _Imaginary is optional >>> even for an implementation that predefines __STDC_IEC_559_COMPLEX__. >>> `#ifdef _Imaginary_I` can be used to detect whether an implementation >>> supports imaginary types. >> >> I don't see how you reach this conclusion. My reading of N1570 says >> an implementation that defines __STDC_IEC_559_COMPLEX__ must have >> imaginary types. Annex G is normative. It clearly states that an >> implementation that defines __STDC_IEC_559_COMPLEX__ must conform to >> its specifications. Section G.2 says _Imaginary is a keyword, and >> there are three imaginary types, float _Imaginary, double _Imaginary, >> and long double _Imaginary. That statement (actually a combination of >> two statements in the annex) is a specification, and so any designated >> implementation must conform to it. > > I believe you're correct, and I was wrong (the second time, not > the first). I honestly don't know how I reached the conclusion > that defining __STDC_IEC_559_COMPLEX__ *doesn't* imply a requirement > to support imaginary types. Most likely I read one document while > thinking it was a different one. > > I apologize for the confusion. No apology needed. >> In section 7.3.1, paragraph 5 says that the two macros 'imaginary' and >> '_Imaginary_I' are defined if and only if the implementation supports >> imaginary types, but I don't see that it gives any license to overrule >> any other statement in the standard. Annex G is clear that there are >> imaginary types, and the implementation must provide them. I don't >> see any wiggle room at all. What is the reasoning behind what you >> say above? > > I now think that an implementation that defines __STDC_IEC_559_COMPLEX__ > (which is optional) must support imaginary types as described in Annex G. > The N1570 draft, of the C11 standard, and of the N3054 draft of C23 > are all consistent on this point. > > Both gcc and clang define __STDC_IEC_559_COMPLEX__ but do not support > imaginary types (with command-line options to make them attempt to be > fully conforming). I find it surprising that they would both be > non-conforming in such a seemingly obvious way. The gcc 12.2.0 manual > doesn't even mention the _Imaginary keyword. What may have happened is that gcc implemented complex types around the time of C99, when complex types were required but Annex G was merely informative (and the last sentence of G.1 says "should conform" rather than "shall conform" as it does in C11). As far as C99 is concerned, gcc and clang are both conforming. Then, when C11 came along, no one noticed the switch in status of Annex G, and since relatively few people care about imaginary types, no one noticed that their absence violated the rules in the new standard. It may be the case that there are other parts of Annex G that either gcc or clang do not satisfy, perhaps because no one has pointed out the (possible) deficiencies. It would be nice if some energetic person would enter a bug report on the gcc bug list site, regarding the missing imaginary types. I have put in gcc bug reports in the past but don't have as much time for that now.