[PATCH 2/2] mapi32: Use the %I length modifier to print pointer-size integers.
jacek at codeweavers.com
Fri Jan 31 07:50:50 CST 2020
On 29.01.2020 05:56, Zebediah Figura wrote:
> "long int" is 32 bits on Windows, so %l will silently truncate the argument to
> 32 bits.
> Signed-off-by: Zebediah Figura <z.figura12 at gmail.com>
> The standard arguments %z, %j, %t are supported by our msvcrt, and could
> conceivably be used instead, but native msvcrt only supports them for 64-bit
> programs, and only with very recent versions of windows. mingw accordingly spits
> out warnings if they are used in 32-bit code. The only other pointer-size length
> modifier that msvcrt accepts is %I.
> Other options include casting to a pointer or a larger type, or using a macro
> similar to PRIxPTR. Note that PRIxPTR itself causes warnings on 32-bit
> platforms, however, because it expands to "x" while the type is defined as "long
> int", so we would have to define our own such macro. Of these options, using %I
> seems to me the most palatable.
> Note that %I is not supported by our ntdll (for traces from e.g. kernelbase),
> but native ntdll supports %I, so there should be no problem adding support for
Unfortunately, this causes warnings on clang:
mapi32_main.c:132:49: warning: format specifies type 'unsigned __int32'
(aka 'unsigned int') but the argument has type 'ULONG_PTR' (aka
'unsigned long') [-Wformat]
Thinking about it some more, I think we should revisit the idea of using
ucrt for builtin modules. With recent changes, we control whole crt when
building Wine, so we can do that. I also have some patches improving
linking with ucrt in my queue. On top of that, we should be able to
default to ucrt for majority of Wine codebase and use standard arguments.
Of course, the biggest problem with that is that we can't do that for
some modules. We can't do that for tests, DLLs that need to link to
specific crt DLLs (like msvcp) and low level DLLs that don't import any
crt DLL. However, maybe it isn't too bad. I'm not worried about tests.
Looking at the size of your recent kernelbase change, maybe problematic
cases will be few enough that we don't need to worry about that too much...
More information about the wine-devel