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.
Hi Zebediah,
On 11/26/19 7:48 PM, Zebediah Figura wrote:
- 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.
I'd say that it looks like a nice solution. Since the warning is obviously bogus, I wonder if we should just skip format attribute in debug.h when __WINE_USE_MSVCRT is defined and we're not using a cross compiler.
- 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.
It's not related to your original problem, but for PE builds (modules using -mno-cygwin to be precise), compatibility is not an issue so there is no reason for using wine_dbgstr_longlong(). I think we should consider using %ll* instead.
Thanks,
Jacek
On 12/4/19 11:28 AM, Jacek Caban wrote:
Hi Zebediah,
On 11/26/19 7:48 PM, Zebediah Figura wrote:
- 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.
I'd say that it looks like a nice solution. Since the warning is obviously bogus, I wonder if we should just skip format attribute in debug.h when __WINE_USE_MSVCRT is defined and we're not using a cross compiler.
Sure, makes sense. I'll try a patch along these lines.
- 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.
It's not related to your original problem, but for PE builds (modules using -mno-cygwin to be precise), compatibility is not an issue so there is no reason for using wine_dbgstr_longlong(). I think we should consider using %ll* instead.
That would be nice, especially for places where it'd be more readable to have decimal traces than hexadecimal. I guess we'd run into warnings when the "long" type is used, but if we skip the format attribute as above we won't have anything to worry about.
(Related question: why don't we just always define __int64 to "long long"?)
Thanks,
Jacek
-
Jacek Caban -
Zebediah Figura