Giving up

[Rumbu]

On Saturday, 6 August 2022 at 08:29:19 UTC, Walter Bright wrote:
> On 8/5/2022 9:43 AM, Max Samukha wrote:
>> Both "123." and "123.E123" is valid C. For some reason, D only 
>> copied the former.
>
> It's to support UFCS (Universal Function Call Syntax). The idea 
> with C compatible aspects of D is to not *silently* break code 
> when there's a different meaning for it. And so, these generate 
> an error message in D (although the error message could be much 
> better).
>
> So, does it work with ImportC?
>
> test2.c:
>   float z = 85886696878585969769557975866955695.E0;
>   long double x = 0x1p-16383;
>
> dmd -c test2.c
>   test2.c(3): Error: number `0x1p-16383` is not representable
>

It is. Since real exponent is biased by 16383 (15 bits), it is 
equivalent of all exponent bits set to 0. Probably it looks 
unimportant, but here it was about a floating point library. 
Subnormal values are part of the floating point standard.

> So the first one does compile as expected with ImportC. Let's 
> try gcc and clang:
>
> gcc -c test2.c
>   test2.c:3:1: warning: floating constant truncated to zero 
> [-Woverflow]
>    long double x = 0x1p-16383;
>    ^
>
> clang -c test.c
>   test2.c:3:17: warning: magnitude of floating-point constant 
> too small for type 'double'; minimum is 4.9406564584124654E-324 
> [-Wliteral-range]
>   long double x = 0x1p-16383;
>

Both gcc and clang are using 64 bits for long double by default. 
You need specific compiler flags to enable 80-bit 
(-mlong-double-80). Also the value needs a L suffix in clang to 
not be interpreted a classic double. Yes, it is truncated to 0, 
but is representable.