[PATCH 2/2] mapi32: Use the %I length modifier to print pointer-size integers.

[Jacek Caban]

Hi Zebediah,

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
> it.


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...


Thanks,

Jacek