1

Func prototype:

foo(_out_ PSIZE_T arg);

Usage:

LARGE_INTEGER offset = {0};

foo(&offset.QuadPart); // Is it safe ?

Reference: http://msdn.microsoft.com/en-us/library/windows/desktop/aa383713(v=vs.85).aspx

James M
  • 18,506
  • 3
  • 48
  • 56
Brans Ds
  • 4,039
  • 35
  • 64

1 Answers1

5

That documentation defines QuadPart as LONGLONG. This defines LONGLONG as a __int64 in 64bit and double in 32 bit. This defines LONGLONG as __int64.

If you compile for 32 bit, then it's definitely wrong, as size_t is an unsigned 32bit integer there. If you compile for 64 bit, it's still wrong, because size_t is an unsigned int and LONGLONG is signed.

So it's not correct in 64 bit either, because LONGLONG is signed and size_t is unsigned, as Steve noted.

Your compiler should flag it as an error anyway.

Martin Ba
  • 37,187
  • 33
  • 183
  • 337
eerorika
  • 232,697
  • 12
  • 197
  • 326
  • Also `size_t` is unsigned, whereas `LONGLONG` is signed. – Steve Jul 12 '14 at 18:42
  • 2
    That documentation is wrong. LONGLONG is not `double` in 64-bit or 32-bit on x86. It is always `__int64`. – Cory Nelson Jul 12 '14 at 18:47
  • agree.. that is error in doc. hate all this datatypes mess. so LARGE_INTEGER is signed in64 and size_t is unsigned int64 – Brans Ds Jul 12 '14 at 18:53
  • signed vs unsigned is no problem at all, it's explicitly allowed to access an object via an lvalue of mismatched signedness. See http://stackoverflow.com/a/7005988/103167 – Ben Voigt Jul 13 '14 at 19:34