Note that in Unix, vsnprintf() returns the TOTAL number of chars needed (add 1 for the null). If the output would overflow the buffer, then you would get a return value larger than the specified buffer size.
In Windoze, vsnprintf() will return -1 if the buffer would be overflowed, and there is no indication of what length the buffer must be. In either case, the buffer will be filled up to the end, but with no terminating null. Microsoft is *not* going to change this, since that would break who-knows how many existing programs that depend on that behavior. -----Original Message----- From: Paul Smith [mailto:psm...@gnu.org] Sent: Tuesday, April 08, 2014 5:07 AM To: Philip Guenther Cc: Rob Juergens; bug-make@gnu.org Subject: Re: error reporting On Mon, 2014-04-07 at 21:26 -0700, Philip Guenther wrote: > I am unable to reproduce this: Based on the offer of MSVC project files I would guess Rob is running on Windows. I expect this is a result of the buggy snprintf()/vsnprintf() implementations in the Windows MSVC compiler (well, by "buggy" I mean not conforming to the ISO C99 standard, which is 15 years old now...) I actually think that MSVC 2013 is supposed to fix this, because the C++11 standard has moved up to incorporate a number of the C99 features (C++03 only relied on C89) which is forcing Microsoft to finally implement them. As John mentions, I rewrote all that code since the 4.0 release to rely only on features available in the C89 standard, which likely fixes this issue as well. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
