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 21:01:29 +0000

Attached is a rewrite of the method vfmtconcat() in output.c. It seems to fix 
the problem.

-----Original Message-----
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 
> 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.

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 
Studio releases?

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

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.


Attachment: output.c
Description: output.c


reply via email to

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