Date: Sat, 18 Sep 2021 20:36:40 +0000
Matthias Kretz pointed out that the proposed rules for C and C++ have different arithmetic conversion rules:
>> float + _Float32 -> _Float32
>> float + std::float32 -> float.
As Jens said, "Not good." It's also unfortunate that I didn't notice this difference sooner. But before I start to panic about this, I want to understand what the impact of this difference is.
When float and _Float32 have the same representation and sets of values, can well-formed C code detect the difference between "float + _Float32 -> _Float32" and "float + _Float32 -> float" without using a _Generic expression? Are there situations where the result type of "float + _Float32" affects the correctness of the program or the behavior of a correct program? It would be very easy to detect this in C++. I can't think of how to detect the difference in C without resorting to _Generic, though I don't know C as well.
If the user writes code that is valid in both C and C++ (assuming that the user has dealt with the fact that _Float32 and std::float32_t are different names for essentially the same type in the two languages), will the fact that "float + _Float32/std::float32_t" have different result types in the two languages cause any differences in behavior?
-----Original Message-----
From: Ext <ext-bounces_at_lists.isocpp.org> On Behalf Of Matthias Kretz via Ext
Sent: Thursday, September 16, 2021 2:01 PM
To: Evolution Working Group mailing list <ext_at_lists.isocpp.org>
Cc: Matthias Kretz <m.kretz_at_gsi.de>; SG6 numerics <sci_at_lists.isocpp.org>; C++ Library Evolution Working Group <lib-ext_at_lists.isocpp.org>; WG14/WG21 liaison mailing list <liaison_at_lists.isocpp.org>; Joseph Myers <joseph_at_codesourcery.com>
Subject: Re: [isocpp-ext] [wg14/wg21 liaison] Report from the recent C/C++ liaison meeting (SG22); includes new floating point types(!)
On Wednesday, 15 September 2021 20:38:27 CEST Aaron Ballman via Ext wrote:
> On Wed, Sep 15, 2021 at 2:27 PM Jens Maurer via Ext
>
> <ext_at_lists.isocpp.org> wrote:
> > On 15/09/2021 20.12, Joseph Myers via Liaison wrote:
> > > On Wed, 15 Sep 2021, Thomas Köppe via Liaison wrote:
> > >> - Currently, the new types are *exclusively* available in the
> > >> _Reserved_name spelling (like "_Bool" was in C99), there is no set
> > >> of
> > >> "pretty" macros (like "bool" was in <stdbool.h>) -- that means that
> > >> if C++
> > >> decides to introduce new pretty names like (std::)float16_t, we have
> > >> no
> > >> immediately interoperable name (like "float16_t") that would be
> > >> valid C,
> > >> since there is no macro "#define float16_t _Float_16", say.
> > >
> > > Also, note that C *does* have typedef names such as _Float16_t -
> > > that's a type whose range and precision are used for evaluating
> > > operations on type _Float16, analogous to float_t and double_t.
> > >
> > > I suggest it would be confusing for float16_t to mean something
> > > different from _Float16_t, and so float16_t may not be a good name
> > > to use to mean
> > > _Float16 in C++.
> >
> > Is there an actual document that specifies exactly what the
> > additional C floating-point support is?
> >
> > The TS does not seem to be freely available.
>
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.o
> pen-std.org%2Fjtc1%2Fsc22%2Fwg14%2Fwww%2Fprojects%2318661&data=04%7C01%7Cdolsen%40nvidia.com%7Cb0d4457e0b4e47e0c2c808d979552e76%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637674229651644478%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=eWQC1tpIWzYQo%2FH4zipBG8DA6pbpxfhxC6uVPDb5T9k%3D&reserved=0 lists the latest drafts before they were rolled into the TS.
Thanks. AFAICS, Part 3 (which defines the new floating-point types) of the TS has not been applied to the latest published C23 WD. But https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg14%2Fwww%2Fdocs%2Fn2601.pdf&data=04%7C01%7Cdolsen%40nvidia.com%7Cb0d4457e0b4e47e0c2c808d979552e76%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637674229651644478%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=CwYM9a%2BfhUxxpQCk9%2BRdqvnoWzYFuFwfRPnQXSMRnj4%3D&reserved=0 proposes the merge.
After reading Section 8 "Conversions" in N2601 (WG14), I believe std::floatN_t and _FloatN need to be distinct types anyway. P1467R4 says "The proposed usual arithmetic conversions when mixing different floating-point types are essentially the same in both languages". But I read it differently:
float + _Float32 -> _Float32
float + std::float32 -> float.
Oh and with "binary80" C23 yields:
long double + _Float64x -> long double Whereas P1467 doesn't cover IEC 60559 extended formats, right?
Would it be an option to keep _Float32 and std::float32 distinct types?
>> float + _Float32 -> _Float32
>> float + std::float32 -> float.
As Jens said, "Not good." It's also unfortunate that I didn't notice this difference sooner. But before I start to panic about this, I want to understand what the impact of this difference is.
When float and _Float32 have the same representation and sets of values, can well-formed C code detect the difference between "float + _Float32 -> _Float32" and "float + _Float32 -> float" without using a _Generic expression? Are there situations where the result type of "float + _Float32" affects the correctness of the program or the behavior of a correct program? It would be very easy to detect this in C++. I can't think of how to detect the difference in C without resorting to _Generic, though I don't know C as well.
If the user writes code that is valid in both C and C++ (assuming that the user has dealt with the fact that _Float32 and std::float32_t are different names for essentially the same type in the two languages), will the fact that "float + _Float32/std::float32_t" have different result types in the two languages cause any differences in behavior?
-----Original Message-----
From: Ext <ext-bounces_at_lists.isocpp.org> On Behalf Of Matthias Kretz via Ext
Sent: Thursday, September 16, 2021 2:01 PM
To: Evolution Working Group mailing list <ext_at_lists.isocpp.org>
Cc: Matthias Kretz <m.kretz_at_gsi.de>; SG6 numerics <sci_at_lists.isocpp.org>; C++ Library Evolution Working Group <lib-ext_at_lists.isocpp.org>; WG14/WG21 liaison mailing list <liaison_at_lists.isocpp.org>; Joseph Myers <joseph_at_codesourcery.com>
Subject: Re: [isocpp-ext] [wg14/wg21 liaison] Report from the recent C/C++ liaison meeting (SG22); includes new floating point types(!)
On Wednesday, 15 September 2021 20:38:27 CEST Aaron Ballman via Ext wrote:
> On Wed, Sep 15, 2021 at 2:27 PM Jens Maurer via Ext
>
> <ext_at_lists.isocpp.org> wrote:
> > On 15/09/2021 20.12, Joseph Myers via Liaison wrote:
> > > On Wed, 15 Sep 2021, Thomas Köppe via Liaison wrote:
> > >> - Currently, the new types are *exclusively* available in the
> > >> _Reserved_name spelling (like "_Bool" was in C99), there is no set
> > >> of
> > >> "pretty" macros (like "bool" was in <stdbool.h>) -- that means that
> > >> if C++
> > >> decides to introduce new pretty names like (std::)float16_t, we have
> > >> no
> > >> immediately interoperable name (like "float16_t") that would be
> > >> valid C,
> > >> since there is no macro "#define float16_t _Float_16", say.
> > >
> > > Also, note that C *does* have typedef names such as _Float16_t -
> > > that's a type whose range and precision are used for evaluating
> > > operations on type _Float16, analogous to float_t and double_t.
> > >
> > > I suggest it would be confusing for float16_t to mean something
> > > different from _Float16_t, and so float16_t may not be a good name
> > > to use to mean
> > > _Float16 in C++.
> >
> > Is there an actual document that specifies exactly what the
> > additional C floating-point support is?
> >
> > The TS does not seem to be freely available.
>
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.o
> pen-std.org%2Fjtc1%2Fsc22%2Fwg14%2Fwww%2Fprojects%2318661&data=04%7C01%7Cdolsen%40nvidia.com%7Cb0d4457e0b4e47e0c2c808d979552e76%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637674229651644478%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=eWQC1tpIWzYQo%2FH4zipBG8DA6pbpxfhxC6uVPDb5T9k%3D&reserved=0 lists the latest drafts before they were rolled into the TS.
Thanks. AFAICS, Part 3 (which defines the new floating-point types) of the TS has not been applied to the latest published C23 WD. But https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg14%2Fwww%2Fdocs%2Fn2601.pdf&data=04%7C01%7Cdolsen%40nvidia.com%7Cb0d4457e0b4e47e0c2c808d979552e76%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637674229651644478%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=CwYM9a%2BfhUxxpQCk9%2BRdqvnoWzYFuFwfRPnQXSMRnj4%3D&reserved=0 proposes the merge.
After reading Section 8 "Conversions" in N2601 (WG14), I believe std::floatN_t and _FloatN need to be distinct types anyway. P1467R4 says "The proposed usual arithmetic conversions when mixing different floating-point types are essentially the same in both languages". But I read it differently:
float + _Float32 -> _Float32
float + std::float32 -> float.
Oh and with "binary80" C23 yields:
long double + _Float64x -> long double Whereas P1467 doesn't cover IEC 60559 extended formats, right?
Would it be an option to keep _Float32 and std::float32 distinct types?
Received on 2021-09-18 15:36:46