I'm getting a crash when I'm converting a double to an uint64_t.

```
std.conv.ConvException@/usr/local/opt/dmd/include/dlang/dmd/std/conv.d(2054): Value (1596) does not match any member value of enum '__c_ulonglong'
```

I've narrowed down the code to this:
```
static import std.conv;
double thing = 42.0;
std.conv.to!(uint64_t)(thing);
```
which works just fine on https://run.dlang.io/ or in a single-file dmd invocation. When I compile and run it locally on my mac as part of a specific large app using dub, it always crashes like this.

Where would I even start debugging this?

DMD64 D Compiler v2.093.0
DUB version 1.22.0, built on Jul  9 2020

> ```
> std.conv.ConvException@/usr/local/opt/dmd/include/dlang/dmd/std/conv.d(2054): Value (1596) does not match any member value of enum '__c_ulonglong'
> ```
well,
```
std.conv.ConvException@/usr/local/opt/dmd/include/dlang/dmd/std/conv.d(2054): Value (42) does not match any member value of enum '__c_ulonglong'
```
but the specific value doesn't matter

On Tuesday, 4 August 2020 at 17:37:56 UTC, drathier wrote:
>> ```
>> std.conv.ConvException@/usr/local/opt/dmd/include/dlang/dmd/std/conv.d(2054): Value (1596) does not match any member value of enum '__c_ulonglong'
>> ```
> well,
> ```
> std.conv.ConvException@/usr/local/opt/dmd/include/dlang/dmd/std/conv.d(2054): Value (42) does not match any member value of enum '__c_ulonglong'
> ```
> but the specific value doesn't matter

full stack trace:
```
std.conv.ConvException@/usr/local/opt/dmd/include/dlang/dmd/std/conv.d(2054): Value (42) does not match any member value of enum '__c_ulonglong'
----------------
source/app.d:864 @safe core.stdc.config.__c_ulonglong std.conv.toImpl!(core.stdc.config.__c_ulonglong, double).toImpl(double) [0x10fa540f8]
source/app.d:864 @safe core.stdc.config.__c_ulonglong std.conv.to!(core.stdc.config.__c_ulonglong).to!(double).to(double) [0x10fa54072]
source/app.d:262 int app.processFromOffset(std.socket.Socket, app.KafkerMode, app.RuntimeState, core.stdc.config.__c_ulonglong, core.stdc.config.__c_ulonglong) [0x10f9d06b5]
source/app.d:175 _Dmain [0x10f9cfcae]
```

Replaced all mentions of uint64_t with ulong, and now it works. Must have an enum called uint64_t defined somewhere in a library I depend on or something? Really wish this was clearer.

On 8/4/20 1:36 PM, drathier wrote:
> I'm getting a crash when I'm converting a double to an uint64_t.
> 
> ```
> std.conv.ConvException@/usr/local/opt/dmd/include/dlang/dmd/std/conv.d(2054): Value (1596) does not match any member value of enum '__c_ulonglong'
> ```
> 
> I've narrowed down the code to this:
> ```
> static import std.conv;
> double thing = 42.0;
> std.conv.to!(uint64_t)(thing);
> ```
> which works just fine on https://run.dlang.io/ or in a single-file dmd invocation. When I compile and run it locally on my mac as part of a specific large app using dub, it always crashes like this.
> 
> Where would I even start debugging this?
> 
> DMD64 D Compiler v2.093.0
> DUB version 1.22.0, built on Jul  9 2020
> 

So a common way to typedef something is to use enum:

enum uint64_t : ulong;

This gives you a new type that works pretty much just like ulong, but will not implicitly convert from ulong.

However, std.conv.to is likely interpreting this as an enumeration type, where it has to match one of the enum members. But since this isn't an enumeration in the standard way, it fails (it has no members!)

This code reproduces the problem on run.dlang.io:

void main()
{
    import core.stdc.config;
    import std.conv;
    auto x = 0.5;
    auto y = x.to!__c_ulonglong;
}

Note the code in druntime which defines __c_ulonglong: https://github.com/dlang/druntime/blob/0db2e65bba7cc319309bd32957763882870d5b03/src/core/stdc/config.d#L121

I'll file a bug.

-Steve

On 8/4/20 2:15 PM, Steven Schveighoffer wrote:
> I'll file a bug.

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

-Steve

On Tuesday, 4 August 2020 at 17:49:56 UTC, drathier wrote:
> Replaced all mentions of uint64_t with ulong, and now it works. Must have an enum called uint64_t defined somewhere in a library I depend on or something? Really wish this was clearer.

BTW I believe the reason that `uint64_t` is an enum (which is being imported by "import std" but isn't converting) solely on macOS/iOS is for compatibility with C++ name mangling.