[SAoC] 'DPP with Linux kernel headers' Project Thread

[Patrick Schluter]

On Saturday, 16 November 2019 at 23:55:45 UTC, Cristian Becerescu 
wrote:
> On Saturday, 16 November 2019 at 18:39:51 UTC, Patrick Schluter 
> wrote:
>> On Saturday, 16 November 2019 at 14:59:51 UTC, Cristian 
>> Becerescu wrote:
>>>
>>> ---Bug #4---
>>> An enum is initialized with a value of 68719476704, which 
>>> produces this:
>>> Error: cannot implicitly convert expression 68719476704L of 
>>> type long to int
>>>
>>> I will probably need to check if some values of the enum are
>>> > int.max, and, if so, declare "enum : long" instead of
>>> "enum".
>>
>> Shouldn't that be done automatically by the D compiler? It's 
>> normal promotion rule, it should reflect in the base type of 
>> the enum. Afaict it is done that way in C (at least as an 
>> extension to gcc).
>
> I tested some cases.
>
> enum e { A = 68719476704 }; // Compiles fine
> enum e { A = 68719476704, B = 1 }; // Still compiles fine
> enum e { B = 1, A = 68719476704 }; // Error: cannot implicitly 
> convert expression 68719476704L of type long to int
>
> I looked through the docs [1] and found this:
> "If the EnumBaseType is not explicitly set, and the first 
> EnumMember has an AssignExpression, it is set to the type of 
> that AssignExpression. Otherwise, it defaults to type int."
>
> [1] https://dlang.org/spec/enum.html

I wanted to interject that it is in violation of the C standard 
(as D has one of its goal that constructs that are syntactically 
identical to C behave the same as in C) but after checking the 
standard C99, it is in fact implementation-defined, with the 
added remark "An implementation may delay the choice of which 
integer type until all enumeration constants have been seen".
So, even in C the compiler may implement as it wishes.