Re: How to clear compile error when using rdrand64_step due to typedef'ing a 64-bit type?

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

On 19 August 2016 at 07:53, Jeffrey Walton wrote:
>>> Forgive my ignorance... 'unsigned long' is 64 bits, which is what that
>>> interface needs (if I am reading the docs correctly).
>>
>> The functions takes a pointer to an unsigned 64-bit type, not
>> necessarily unsigned long.
>
> Thanks again Jonathon. I guess this is what I don't quite
> understand... From the preprocessor, GCC tells me the UINT64 type is
> the following on x86_64:
>
>     #define __UINT64_TYPE__ long unsigned int
>
> If 'long unsigned int' is the 64-bit integer and it meets alignment

It's not *the* 64-bit integer, it's *a* 64-bit integer.

On LP64 platforms
> and size requirements (as a 'minimum' of sorts), then why can't it be
> used where the 64-bit type is required (i..e, the pointer in the call
> to _rdrand64_step).

Because that's how the C++ type system works.

__UINT64_TYPE__ is the underlying type of uint64_t. The signature for
the function you're calling is:

../gcc/config/i386/immintrin.h:_rdrand64_step (unsigned long long *__P)

That's not uint64_t, so don't try to use uint64_t. Use the type the
function is declared to take.

The rules of C++ don't say you can freely mix pointers to distinct
types as long as they are a bit samey. You can't mix int* and long*
when sizeof(long) == sizeof(int) and you can't mix unsigned long long*
and unsigned long* when sizeof(unsigned long long) == sizeof(unsigned
long).

You've basically gone chasing after some unrelated definition (that of
uint64_t) which has nothing to do with _rdrand64(), looking at
unrelated implementation details of that different type, and the
simple solution is to just use the type in the function declaration.