Re: error reporting
Note that in Unix, vsnprintf() returns the TOTAL number of chars needed (add 1 for the null). This is not correct. The buffer size (that you pass in) is the total number of bytes available (and the most the function shall use, including the terminator); but the *return* is the strlen() that would have resulted had the buffer been big enough. If this is the buffer size you passed in, the output has been truncated, in order to fit in the terminator, by one byte; but the return doesn't include the terminator. If the output would overflow the buffer, then you would get a return value larger than the specified buffer size. Yes, and you need to add one to the return value to get the buffer size you need for the subsequent call that'll get the job done properly. The function hasn't added one for the terminator: you need to do that. In Windoze, vsnprintf() will return -1 if the buffer would be overflowed, This is quite usual amongst iron-age implementations of libc. Eddy. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: error reporting
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? Don't hold your breath - it might be there, but think about the upgrade treadmill for a moment and you'll see why it's not in MS's interests to support anything other than sure, we can read the old project file and upgrade it to the incompatible new version. That way, the developer who has splurged on the new version shares unusable project files with the rest of the team, who are pressured thereby into upgrading. Same as the reason word processor file formats have to change at every release - use network effects to turn your customers into stooges for your marketing department. Eddy. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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
RE: error reporting
You are correct in that building make-4.0 on solaris does not show that problem. However building with VS2013 does not fix it. Attached are 2013 files and updated other files -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. make_msvc_net2008.sln Description: make_msvc_net2008.sln make_msvc_net2008.vcproj Description: make_msvc_net2008.vcproj make_msvc_net2012.sln Description: make_msvc_net2012.sln make_msvc_net2012.vcxproj Description: make_msvc_net2012.vcxproj make_msvc_net2013.sln Description: make_msvc_net2013.sln make_msvc_net2013.vcxproj Description: make_msvc_net2013.vcxproj ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
RE: error reporting
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
Re: error reporting
On Tue, 2014-04-08 at 20:15 +, 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. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
RE: error reporting
Attached is a rewrite of the method vfmtconcat() in output.c. It seems to fix
the problem.
-Original Message-
From: Paul Smith [mailto:psm...@gnu.org]
Sent: Tuesday, April 08, 2014 2:00 PM
To: Rob Juergens
Cc: Philip Guenther; bug-make@gnu.org
Subject: Re: error reporting
On Tue, 2014-04-08 at 20:15 +, 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.
/* Output to stdout / stderr for GNU make
Copyright (C) 2013 Free Software Foundation, Inc.
This file is part of GNU Make.
GNU Make is free software; you can redistribute it and/or modify it under the
terms of the GNU General Public License as published by the Free Software
Foundation; either version 3 of the License, or (at your option) any later
version.
GNU Make is distributed in the hope that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with
this program. If not, see http://www.gnu.org/licenses/. */
#include makeint.h
#include job.h
/* GNU make no longer supports pre-ANSI89 environments. */
#include assert.h
#include stdio.h
#include stdarg.h
#ifdef HAVE_UNISTD_H
# include unistd.h
#endif
#ifdef HAVE_FCNTL_H
# include fcntl.h
#else
# include sys/file.h
#endif
#ifdef WINDOWS32
# include windows.h
# include io.h
# include sub_proc.h
#endif /* WINDOWS32 */
struct output *output_context = NULL;
unsigned int stdio_traced = 0;
#define OUTPUT_NONE (-1)
#define OUTPUT_ISSET(_out) ((_out)-out = 0 || (_out)-err = 0)
#ifdef HAVE_FCNTL
# define STREAM_OK(_s)((fcntl (fileno (_s), F_GETFD) != -1) || (errno !=
EBADF))
#else
# define STREAM_OK(_s)1
#endif
/* I really want to move to gnulib. However, this is a big undertaking
especially for non-UNIX platforms: how to get bootstrapping to work, etc.
I don't want to take the time to do it right now. Use a hack to get a
useful version of vsnprintf() for Windows. */
#ifdef __VMS
# define va_copy(_d, _s) ((_d) = (_s))
#endif
#ifdef _MSC_VER
# define va_copy(_d, _s) ((_d) = (_s))
# define snprintf msc_vsnprintf
static int
msc_vsnprintf (char *str, size_t size, const char *format, va_list ap)
{
int len = -1;
if (size 0)
len = _vsnprintf_s (str, size, _TRUNCATE, format, ap);
if (len == -1)
len = _vscprintf (format, ap);
return len;
}
#endif
/* Write a string to the current STDOUT or STDERR. */
static void
_outputs (struct output *out, int is_err, const char *msg)
{
if (! out || ! out-syncout)
{
FILE *f = is_err ? stderr : stdout;
fputs (msg, f);
fflush (f);
}
else
{
int fd = is_err ? out-err : out-out;
int len = strlen (msg);
int r
Re: error reporting
On Tue, 2014-04-08 at 21:01 +, Rob Juergens wrote: Attached is a rewrite of the method vfmtconcat() in output.c. It seems to fix the problem. Thanks, but as Philip mentioned earlier I've completely rewritten the output.c file and callers of it so they use only C89 compliant functions (so no vsnprintf(), only sprintf() and vsprintf()). The latest code is available in the Git repository, available through Savannah: https://savannah.gnu.org/projects/make/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: error reporting
On Mon, Apr 7, 2014 at 4:45 PM, Rob Juergens rjuerg...@esri.com wrote: Given the make file (makefile): -- foo : bar -- gmake 3.75 gives this: gmake: *** No rule to make target 'bar', needed by 'foo'. Stop. gmake 4.0 gives this: gmake: ***. stop. This has caused a lot of time trying to figure out what is wrong with the makefile. A big step backward in error reporting. Please fix this. I am unable to reproduce this: : morgaine; ls -l total 2 -rw-rw-r-- 1 guenther wheel 10 Apr 7 21:22 Makefile : morgaine; cat Makefile foo : bar : morgaine; gmake --version GNU Make 4.0 Built for x86_64-unknown-openbsd5.5 Copyright (C) 1988-2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. : morgaine; gmake gmake: *** No rule to make target 'bar', needed by 'foo'. Stop. : morgaine; What information about your situation did you leave out? Philip Guenther ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: error reporting
On 4/7/2014 11:26 PM, Philip Guenther wrote: On Mon, Apr 7, 2014 at 4:45 PM, Rob Juergens rjuerg...@esri.com wrote: Given the make file (makefile): -- foo : bar -- gmake 3.75 gives this: gmake: *** No rule to make target 'bar', needed by 'foo'. Stop. gmake 4.0 gives this: gmake: ***. stop. This has caused a lot of time trying to figure out what is wrong with the makefile. A big step backward in error reporting. Please fix this. I am unable to reproduce this: : morgaine; ls -l total 2 -rw-rw-r-- 1 guenther wheel 10 Apr 7 21:22 Makefile : morgaine; cat Makefile foo : bar : morgaine; gmake --version GNU Make 4.0 Built for x86_64-unknown-openbsd5.5 Copyright (C) 1988-2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. : morgaine; gmake gmake: *** No rule to make target 'bar', needed by 'foo'. Stop. : morgaine; What information about your situation did you leave out? I was able to reproduce a similar issue on VAX/VMS 7.3 with Gnu Make 4.0 from the release tarball. Under some code paths the output buffer size is initialized to zero length and output gets truncated. The buffer expansion algorithm was to double the size of the buffer if it detects that there is not room for the output of vsnprintf, but since the size starts at zero in some cases, zero * 2 is still zero, so the buffer was not expanded. Which results in the output reported above. I did not see this issue on Alpha or IA64/VMS 8.4, and did not find out why it works on that platform and failed on VAX/VMS, since I would have expected similar behavior in both cases. The section of code that causes the problem has been completely replaced in master. Regards, -John ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
