[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: error reporting
From: |
Rob Juergens |
Subject: |
RE: error reporting |
Date: |
Tue, 8 Apr 2014 20:15:22 +0000 |
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:address@hidden
Sent: Tuesday, April 08, 2014 5:07 AM
To: Philip Guenther
Cc: Rob Juergens; address@hidden
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.