<div dir="ltr"><div>But why not just using they definitions from stdint.h on platforms where this one exists ?</div><div><br></div><div>Idea is that the way is right now creates lot of conversions warnings if using NIF in mix with other libs that respects the <stdint.h> standard. And I need to put lot of casts to avoid them</div><div><br></div><div>Silviu<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 29, 2019 at 10:40 AM Mikael Pettersson <<a href="mailto:mikpelinux@gmail.com">mikpelinux@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Aug 28, 2019 at 11:30 PM Caragea Silviu <<a href="mailto:silviu.cpp@gmail.com" target="_blank">silviu.cpp@gmail.com</a>> wrote:<br>
><br>
> Hello,<br>
><br>
> On a Mac OS 10.13.6 x64 in the osx headers the uint_64_t is defined as:<br>
><br>
> #ifndef _UINT64_T<br>
> #define _UINT64_T<br>
> typedef unsigned long long uint64_t;<br>
> #endif /* _UINT64_T */<br>
><br>
> But NIF function enif_get_uint64 is defined as<br>
><br>
> #  define enif_get_uint64 enif_get_ulong<br>
><br>
> which accepts an unsigned long<br>
><br>
> Any idea why is like this ?<br>
<br>
The definitiion of enif_get_uint64 is conditional on the size of C's<br>
long type; the case you quoted only applies when long _is_ 64 bits.<br>
<br>
(Typically long is 32 bits on 32-bit machines and 64 bits on 64-bit<br>
machines, with long long always being 64 bits, but some OS:es<br>
(Windows) insists on keeping long 32 bits even in 64-bit environments.<br>
This is just one of many small details we have to handle when writing<br>
C code that's supposed to work on many CPUs and OS:es.)<br>
</blockquote></div>