Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: "A diagram of C23 basic types"
Date: Tue, 06 May 2025 15:06:50 -0700
Organization: A noiseless patient Spider
Lines: 56
Message-ID: <865xid2y2t.fsf@linuxsc.com>
References: <87y0wjaysg.fsf@gmail.com> <20250403150210.000020f8@yahoo.com> <86selt8lxv.fsf@linuxsc.com> <20250428162738.00007c1d@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Wed, 07 May 2025 00:06:54 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="8a8b4824d7f5648ca1e397f9075ff09b";
	logging-data="4118405"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/bQJRg51HC/KhGj4t+O43HURfL6RZfbwE="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:c0JSSPRAWIn+HeXsCq5NW1G4C6A=
	sha1:3DXXXOQLow/Ets7p7kBqnGdE8Bw=
Bytes: 3678

Michael S <already5chosen@yahoo.com> writes:

> 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.

Actually I didn't know about that.  To me your posting upthread
is enough to see where you're coming from (or at least I think
it is).

> 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.

I acknowledge that people feel that there is a problem in need
of being addressed.  The question is not whether a problem
exists but what exactly is the problem and how should it be
addressed?  For example, rather than tie a proposal to some
future release of the ISO C standard, maybe the question should
be addressed by Posix.  It's hard to have a fruitful discussion
about what the answer should be before people understand and
agree what the problem is that needs to be addressed.