On 19 August 2016 at 08:48, Jonathan Wakely wrote: > 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 Oops, sorry for the incomplete sentence. I meant to say: On LP64 platforms unsigned long has the same representation as unsigned long long, but it's still a separate type. On ILP32 platforms unsigned long has the same representation as unsigned int, but it's still a separate type. A char has the same representation as one of signed char or unsigned char, but it's still a separate type. >> 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.
