Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Michael S Newsgroups: comp.lang.c Subject: Re: "A diagram of C23 basic types" Date: Mon, 28 Apr 2025 16:27:38 +0300 Organization: A noiseless patient Spider Lines: 53 Message-ID: <20250428162738.00007c1d@yahoo.com> References: <87y0wjaysg.fsf@gmail.com> <20250403150210.000020f8@yahoo.com> <86selt8lxv.fsf@linuxsc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Injection-Date: Mon, 28 Apr 2025 15:27:39 +0200 (CEST) Injection-Info: dont-email.me; posting-host="5a0c3291da4a07eb884b83d5c1f5f8d1"; logging-data="3151006"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/R7Oz7pRA6mqVlhMzGehaUiJOA8V8C5hQ=" Cancel-Lock: sha1:eaA83P8FFQWod7FoB4w38WkrE/Q= X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32) On Sun, 27 Apr 2025 12:05:16 -0700 Tim Rentsch wrote: > Michael S writes: > > > On Wed, 02 Apr 2025 16:59:59 +1100 > > Alexis wrote: > > > >> Thought people here might be interested in this image on Jens > >> Gustedt's blog, which translates section 6.2.5, "Types", of the C23 > >> standard into a graph of inclusions: > >> > >> https://gustedt.wordpress.com/2025/03/29/a-diagram-of-c23-basic-types/ > >> > > > > That's a little disappointing. > > IMHO, C23 should have added optional types _Binary32, _Binary64, > > _Binary128 and _Binary256 that designate their IEEE-754 namesakes. > > Plus, a mandatory requirement that if compiler supports any of > > IEEE-754 binary types then they have to be accessible by > > above-mentioned names. > > I see where you're coming from, I suppose, you know it because you followed my failed attempt to improve speed and cross-platform consistency of gcc IEEE binary128 arithmetic. Granted, in this case absence of common name for the type was much smaller obstacle than general indifference of gcc maintainers. So, yes, on the "producer" side the problem of absence of common name was annoying but could be regarded as minor. Apart from being a "producer", quite often I am on the other side, wearing a hat of consumer of extended precision types. When in this role, I feel that the relative weight of inconsistent type names is rather significant. I'd guess that it is even more significant for people whose work, unlike mine, is routinely multi-platform. I would not be surprised if for many of them it ends up as main reason to refrain completely from use IEEE binary128 in their software; even when it causes complications to their work and when the type is readily available, under different names, on all platforms they care about. > but I disagree with the suggested > addition; it simultaneously does too much and not enough. If > someone wants some capability along these lines, the first step > should be to understand what the underlying need is, and then to > figure out how to accommodate that need. The addition described > above creates more problems than it solves. IMHO, a need for a common name for IEEE binary128 exists for quite some time. For IEEE binary256 the real need didn't emerge yet. But it will emerge in the hopefully near future.