[PATCH 1/2] include: Don't use the printf format attribute when compiling against msvcrt and not cross-compiling.
Since it will spit out bogus warnings in the case we use Microsoft-specific extensions. Signed-off-by: Zebediah Figura <z.figura12(a)gmail.com> --- include/wine/debug.h | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/include/wine/debug.h b/include/wine/debug.h index 8985163894..2a63f4351d 100644 --- a/include/wine/debug.h +++ b/include/wine/debug.h @@ -88,7 +88,11 @@ struct __wine_debug_channel #define __WINE_DBG_LOG(args...) \ wine_dbg_log( __dbcl, __dbch, __FUNCTION__, args); } } while(0) +#if !defined(__WINE_USE_MSVCRT) || defined(__MINGW32__) #define __WINE_PRINTF_ATTR(fmt,args) __attribute__((format (printf,fmt,args))) +#else +#define __WINE_PRINTF_ATTR(fmt,args) +#endif #ifdef WINE_NO_TRACE_MSGS -- 2.25.0
"long int" is 32 bits on Windows, so %l will silently truncate the argument to 32 bits. Signed-off-by: Zebediah Figura <z.figura12(a)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. dlls/mapi32/imalloc.c | 4 ++-- dlls/mapi32/mapi32_main.c | 6 +++--- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/dlls/mapi32/imalloc.c b/dlls/mapi32/imalloc.c index 3e95a6c7cd..561df1a60a 100644 --- a/dlls/mapi32/imalloc.c +++ b/dlls/mapi32/imalloc.c @@ -114,7 +114,7 @@ static ULONG WINAPI IMAPIMalloc_fnRelease(LPMALLOC iface) */ static LPVOID WINAPI IMAPIMalloc_fnAlloc(LPMALLOC iface, SIZE_T cb) { - TRACE("(%p)->(%ld)\n", iface, cb); + TRACE("(%p)->(%Id)\n", iface, cb); return LocalAlloc(LMEM_FIXED, cb); } @@ -124,7 +124,7 @@ static LPVOID WINAPI IMAPIMalloc_fnAlloc(LPMALLOC iface, SIZE_T cb) */ static LPVOID WINAPI IMAPIMalloc_fnRealloc(LPMALLOC iface, LPVOID pv, SIZE_T cb) { - TRACE("(%p)->(%p, %ld)\n", iface, pv, cb); + TRACE("(%p)->(%p, %Id)\n", iface, pv, cb); if (!pv) return LocalAlloc(LMEM_FIXED, cb); diff --git a/dlls/mapi32/mapi32_main.c b/dlls/mapi32/mapi32_main.c index 0dcc811c24..ac83062679 100644 --- a/dlls/mapi32/mapi32_main.c +++ b/dlls/mapi32/mapi32_main.c @@ -129,7 +129,7 @@ HRESULT WINAPI MAPIInitialize(LPVOID init) ULONG WINAPI MAPILogon(ULONG_PTR uiparam, LPSTR profile, LPSTR password, FLAGS flags, ULONG reserved, LPLHANDLE session) { - TRACE("(0x%08lx %s %p 0x%08x 0x%08x %p)\n", uiparam, + TRACE("(0x%08Ix %s %p 0x%08x 0x%08x %p)\n", uiparam, debugstr_a(profile), password, flags, reserved, session); if (mapiFunctions.MAPILogon) @@ -149,7 +149,7 @@ ULONG WINAPI MAPILogon(ULONG_PTR uiparam, LPSTR profile, LPSTR password, ULONG WINAPI MAPILogoff(LHANDLE session, ULONG_PTR uiparam, FLAGS flags, ULONG reserved ) { - TRACE("(0x%08lx 0x%08lx 0x%08x 0x%08x)\n", session, + TRACE("(0x%08Ix 0x%08Ix 0x%08x 0x%08x)\n", session, uiparam, flags, reserved); if (mapiFunctions.MAPILogoff) @@ -167,7 +167,7 @@ ULONG WINAPI MAPILogoff(LHANDLE session, ULONG_PTR uiparam, FLAGS flags, HRESULT WINAPI MAPILogonEx(ULONG_PTR uiparam, LPWSTR profile, LPWSTR password, ULONG flags, LPMAPISESSION *session) { - TRACE("(0x%08lx %s %p 0x%08x %p)\n", uiparam, + TRACE("(0x%08Ix %s %p 0x%08x %p)\n", uiparam, debugstr_w(profile), password, flags, session); if (mapiFunctions.MAPILogonEx) -- 2.25.0
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(a)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
participants (2)
-
Jacek Caban -
Zebediah Figura