[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: error reporting
RE: error reporting
Tue, 8 Apr 2014 21:01:29 +0000
Attached is a rewrite of the method vfmtconcat() in output.c. It seems to fix
From: Paul Smith [mailto:address@hidden
Sent: Tuesday, April 08, 2014 2:00 PM
To: Rob Juergens
Cc: Philip Guenther; address@hidden
Subject: Re: error reporting
On Tue, 2014-04-08 at 20:15 +0000, Rob Juergens wrote:
> 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
> In Windoze, vsnprintf() will return -1 if the buffer would be
> overflowed, and there is no indication of what length the buffer must
Yes, I'm well aware of the difference in behavior, unfortunately :-/.
> Microsoft is *not* going to change this, since that would break
> who-knows how many existing programs that depend on that behavior.
Well, that's a shame: if true MSVC will never be a conforming compiler
implementation for C++11 or any newer C++ standard.
The C++11 standard clearly states that the return value of the
(standard) vsnprintf() function must be the "number of characters that would
have been written if [the buffer size] had been sufficiently large, not
counting the terminating null character". This is basically the exact text for
the C99 standard, imported into the C++11 standard.
Microsoft is on the C++ standards committee and they certainly were aware of
this, so my hope is they have a plan to allow for both "legacy"
implementations and "conforming" implementations.
> Attached are 2013 files and updated other files
I'm really not excited about the prospect of continuing to add new project
files every year for each new version of Visual Studio. Isn't there any sort
of backward-compatibility that allows the older files to work in newer Visual
Also, is there any way to get these project files out of the root directory?
I'd be a lot more sanguine about them if we could put them into the "w32"
subdirectory, or in an "msvc" subdirectory or something and get them out of the
To my mind the only reason to ship Visual Studio project files with GNU make is
if there are people who want to develop and enhance GNU make itself, and who
want to use Visual Studio to do it. For people who just want to build GNU make
on Windows and use the result for other projects, surely it's easier to just
run a .bat build file or maybe use an nmake file to build make.exe; that's all
you need. Visual Studio seems like real overkill for that.