August 06

On Saturday, 6 August 2022 at 06:03:59 UTC, Vladimir Panteleev wrote:

>

On Friday, 5 August 2022 at 15:36:06 UTC, Rumbu wrote:
[...]
The last version where this compiled successfully was D 0.116, released on March 7, 2005.

Perhaps you may have had a bug in your test suite which caused these lines to not be compiled.

The file named intel.d was introduced with

commit b5b1458585b65b9072f907de4c3f09b1b4790e26 (tag: v0.9.1)
Author: razvan.stefanescu <rumbu@rumbu.ro>
Date:   Wed Jan 31 23:09:19 2018 +0200

    a lot of changes

it seems that nobody, including me, ever executed dub test. Archiving and CI would be nice for packages registered with code.dlang.org.

August 06
On 8/6/2022 2:02 AM, Tim wrote:
> It could silently break code if the right function is defined. The following example is valid in C and D (except import/include), but prints a different value:
> 
> ```D
> // #include <stdio.h>
> import core.stdc.stdio;
> 
> int E2(int i)
> {
>      return i;
> }
> 
> int main()
> {
>      float f = 123.E2;
>      printf("%f\n", f);
>      return 0;
> }


Congrats, you got me there!
August 06
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).

UFCS could still be supported with the exception of functions named like exponents. (I am not advocating for it.)

> aaaand, the truth comes out. It is not representable, it is truncated to 0. Technically, ImportC should accept it. But if it does, doesn't it mislead users into thinking it is non-zero?
>
> We've got the right choice here, but it's definitely a judgement call.

No objections to this.

August 06
On Saturday, 6 August 2022 at 11:08:05 UTC, Max Samukha wrote:
> 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).
>
> UFCS could still be supported with the exception of functions named like exponents. (I am not advocating for it.)
>
>> aaaand, the truth comes out. It is not representable, it is truncated to 0. Technically, ImportC should accept it. But if it does, doesn't it mislead users into thinking it is non-zero?
>>
>> We've got the right choice here, but it's definitely a judgement call.
>
> No objections to this.

May be we need some warnings about ambiguity, but incompability with C in base things, as literals is not an option.

Same code compiled different with ImportC but not D, ough.


August 06
On 8/6/2022 4:08 AM, Max Samukha wrote:
> UFCS could still be supported with the exception of functions named like exponents. (I am not advocating for it.)

We could, and enter the inevitable bug report from the baffled user who can't figure out why UFCS stopped working for his algorithm-generated function names.

At some point, we just have to accept there's going to be a compromise.
August 06
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.


August 06
On 8/6/22 19:27, Rumbu wrote:
> 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.

Seems you should just use a long double/real literal?

real x = 0x1p-16383L; // (works)
August 06

Good catch!

On Saturday, 6 August 2022 at 17:27:30 UTC, Rumbu wrote:

> >

[...]
long double x = 0x1p-16383;

dmd -c test2.c
test2.c(3): Error: number 0x1p-16383 is not representable

It is.

But not in the double type and 0x1p-16383 is a double not a long double.

>

[...]

>

Also the value needs a L suffix in clang to not be interpreted a classic double.

GCC is no exception and needs the L suffix, too. [1]

[1] https://en.cppreference.com/w/cpp/language/floating_literal

August 06
On 8/6/2022 1:29 PM, Timon Gehr wrote:
> Seems you should just use a long double/real literal?
> 
> real x = 0x1p-16383L; // (works)

Looks like that settles it. (Why didn't I notice that? Sheesh!)
August 07
On 07/08/2022 10:45 AM, Walter Bright wrote:
> On 8/6/2022 1:29 PM, Timon Gehr wrote:
>> Seems you should just use a long double/real literal?
>>
>> real x = 0x1p-16383L; // (works)
> 
> Looks like that settles it. (Why didn't I notice that? Sheesh!)

Needs a better error message.

https://issues.dlang.org/show_bug.cgi?id=23284