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