2016.05.09 23:01 "Re: [Tiff] snprintf and MSVC 2015", by Roger Leigh

On 09/05/2016 20:45, Edward Lam wrote:

On 09/05/2016 3:29 PM, Roger Leigh wrote:

It would be useful to know what exactly HAVE_SNPRINTF is set to for these failing builds I can't reproduce.

- is it undefined, or set to a value

- should the above patch be undef'ing it if defined rather than defining to nothing?

HAVE_SNPRINTF is undefined in the case where it fails for me in Visual Studio

2015. Note that the actual value of HAVE_SNPRINTF does not matter since the code

testing for it doesn't look at its value.

OK. For clarity and consistency with the other defines, I think

#else
#define HAVE_SNPRINTF 1

would be a bit better (adding 1 at the end)

It is odd that you're failing to reproduce the problem. Several other people and

myself can easily reproduce this problem so I think the reason why you're not

seeing this is because your build tools are not matching ours. Which Windows SDK

version are you using? Perhaps you're either not using Visual Studio 2015 and/or

an earlier Windows SDK version where snprintf() wasn't implemented yet. I've

attached a build log from by Visual Studio 2015 installation using the "VS2015

x64 Native Tools Command Prompt" start menu item and running "nmake /f Makefile.vc".

I've been able to reproduce it now, but the reason is defying
explanation. If I open a VS2015 native tools prompt and run nmake, it
now errors out just like your log, and the patch fixes it. However...
this is exactly what I was doing when it succeeded, and I'm still
building in a new checkout each time, so I'm unsure what the trigger is.

Even when it was failing, it would still build with cmake though; only nmake failed. This makes sense though--the cmake build uses tif_config.h.cmake.in instead. The only situation I can see this maybe failing is if you built with nmake, it generated a broken tif_config.h in the srcdir, and then you do an out-of-tree cmake build, and it generates a good tif_config.h in the builddir, but the one in the srcdir is used instead. If anyone is seeing a failure with cmake, could you retry in a clean checkout to see if that helps?

So looks like the patch is fine to apply, perhaps with the modification
suggested above, but I'm still confused as to why the behaviour
differences are seen.

Regards,
Roger