LONG_PTR and friends

Zebediah Figura z.figura12 at gmail.com
Tue Nov 26 12:48:38 CST 2019


Moving modules to use msvcrt has had the unfortunate side effect that 
tracing LONG_PTR/DWORD_PTR/etc. using %ld no longer works—since a long 
is 32 bits wide as far as msvcrt is concerned, it cuts off top 32 bits 
on 64-bit platforms. This has already caused me some grief while debugging.

I'm not sure what we can use in its place, though:

* Our msvcrt supports the standard %z, %j, %t. I originally assumed this 
would work, but unfortunately it seems native msvcrt only supports this 
on 64-bit and only in very recent versions of Windows. mingw-w64 
accordingly spits out warnings if we try to use it in 32-bit code. I 
think ucrtbase always supports them, but only some modules use ucrtbase 
(and especially considering e.g. tests I doubt that converting 
everything else to use ucrtbase is a good idea).

* Both builtin and native msvcrt always support %I, but it's nonstandard 
and it spits out warnings when you try to use it when not compiling with 
mingw.

* PRIxPTR (etc.) almost works, except that on 32-bit both mingw and the 
native compiler spit out warnings because it expands to "x" while the 
type is defined as "long int".

* Along those lines I guess we could define our own PRI-type macro...

* We could also cast to (void *), or cast to a 64-bit type and use 
wine_dbgstr_longlong(), though this has the unfortunate side effect of 
forcing us to trace in hexadecimal.



More information about the wine-devel mailing list