bug-make
[Top][All Lists]
Advanced

[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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]