Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
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 <tr.17687@z991.linuxsc.com> wrote:

> Michael S <already5chosen@yahoo.com> writes:
> 
> > On Wed, 02 Apr 2025 16:59:59 +1100
> > Alexis <flexibeast@gmail.com> 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.