[erlang-questions] strange definition of enif_get_uint64

[Caragea Silviu]

But why not just using they definitions from stdint.h on platforms where
this one exists ?

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

Silviu

On Thu, Aug 29, 2019 at 10:40 AM Mikael Pettersson <mikpelinux@REDACTED>
wrote:

> On Wed, Aug 28, 2019 at 11:30 PM Caragea Silviu <silviu.cpp@REDACTED>
> wrote:
> >
> > Hello,
> >
> > On a Mac OS 10.13.6 x64 in the osx headers the uint_64_t is defined as:
> >
> > #ifndef _UINT64_T
> > #define _UINT64_T
> > typedef unsigned long long uint64_t;
> > #endif /* _UINT64_T */
> >
> > But NIF function enif_get_uint64 is defined as
> >
> > #  define enif_get_uint64 enif_get_ulong
> >
> > which accepts an unsigned long
> >
> > Any idea why is like this ?
>
> The definitiion of enif_get_uint64 is conditional on the size of C's
> long type; the case you quoted only applies when long _is_ 64 bits.
>
> (Typically long is 32 bits on 32-bit machines and 64 bits on 64-bit
> machines, with long long always being 64 bits, but some OS:es
> (Windows) insists on keeping long 32 bits even in 64-bit environments.
> This is just one of many small details we have to handle when writing
> C code that's supposed to work on many CPUs and OS:es.)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20190829/e9d88a8c/attachment.htm>