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.
