On Tue, Jan 29, 2019 at 12:28:38PM -0500, Andrew Piskorski wrote: > Hm, Ns_ThreadId() returns type uintptr_t, so why does LogToDString() > use PRIxPTR in the first place? Shouldn't it use PRIuPTR, with a "u" > for unsigned? I think so, so I switched to that.
Nope, I was confused. PRIxPTR takes an unsigned int and displays it as hexadecimal output, which is what NaviServer wants. PRIuPTR also takes an unsigned int, but displays it as decimal, so by using that I inadvertently changed the log output. So I reverted that (trivial) change in my BitBucket fork. Here's a nice cheat sheet listing PRIxPTR and the other C99 macros for integers: https://en.cppreference.com/w/c/types/integer > Here's the fix I'm using now: > > > https://bitbucket.org/apiskors/naviserver/commits/16e6658319ae9595e7d874e68086e482f2f74f85 > Fix garbled log output on Windows, PRIuPTR now gives I64u or I32u there. As Gustaf explained to me, Microsoft added inttypes.h with PRIxPTR and other (limited) C99 support way back in 2013: https://blogs.msdn.microsoft.com/vcblog/2013/07/19/c99-library-support-in-visual-studio-2013/ So my fix for PRIxPTR on Windows wouldn't be necessary if I was using a recent Microsoft compiler and libraries with proper inttypes.h support. However, it's a good and useful change for people stuck with older compilers, and should not hurt anything for newer compilers. Btw, "naviserver/include/nsthread.h" has "#ifndef HAVE_CONFIG_H" definitions in it for MSVC, c. line 280. I found that if I add a "#define HAVE_INTTYPES_H 1" there, then the Windows build definitely tries to use inttypes.h - but in my case, fails because it can't find the file. -- Andrew Piskorski <a...@piskorski.com> _______________________________________________ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
