On 05/01/2017 01:39 PM, Simon Sobisch wrote:
Hi,I've just got GCC7 (build from svn worked like a charm, even if it took hours but I was warned) and like the new warnings and hints very much. When compiling GnuCOBOL from vcs (sources on mount, therefore the long path) I got one warning with multiple and very long tilde lines. /media/sf_Entwicklung/GnuCOBOL/gnu-cobol-2.0_texi/cobc/typeck.c: In function 'cb_build_registers': /media/sf_Entwicklung/GnuCOBOL/gnu-cobol-2.0_texi/cobc/typeck.c:1064:30: warning: 'snprintf' output may be truncated before the last format character [-Wformat-truncation=] snprintf (buff, (size_t)17, "%02d/%02d/%02d%02d%c%02d%c%02d", ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /media/sf_Entwicklung/GnuCOBOL/gnu-cobol-2.0_texi/cobc/typeck.c:1064:2: note: 'snprintf' output between 17 and 63 bytes into a destination of size 17 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ current_compile_time.second); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ It looks like the source in the lines between are missing (the number of tildes is correct). The source reads: snprintf (buff, (size_t)17, "%02d/%02d/%02d%02d%c%02d%c%02d", current_compile_time.day_of_month, current_compile_time.month, current_compile_time.year % 100, current_compile_time.hour, '.', current_compile_time.minute, '.', current_compile_time.second);
Hmm, that's quite odd. I'm not able to reproduce this "effect" and I have never seen anything like it. My first thought was that it could be a problem with the terminal you are using (try compiling with -fno-diagnostics-color to see if it improves) but since you presumably copied the error message above from the terminal that's probably not going to help. If it doesn't, can you please create a new bug and attach to it a preprocessing translation unit (compile the source file with -E and save the output)? Also include the full set of command line options you invoked the compiler with when you got the "invisible" message.
Thank you for this compiler! Simon BTW: is it really useful to have the complete function in the output message? The output may get *very* long...
You mean the complete function call in the note, including the arguments? GCC tries to provide as much useful context in diagnostic messages as necessary to help users see their root cause. The trend has been toward more verbose messages, and so some message can get long (that's especially true for C++ code heavy on templates). In this case, showing the full call is probably not particularly helpful but I have never though about it as being a problem. Each diagnostic message printed by GCC is associated with some location in the source code, often a declaration or a full expression, but sometimes a subexpression. In this case the choice is between the location of the format string and that of the function call. The warning is associated with the location of the format so the note is attached to the whole call. Off the top of my head I can't think of anything else to attach it to that would make sense. Martin PS gcc-bugs is used for automated emails sent in response to changes to the GCC Bugzilla. Please use gcc-help for questions about GCC (or open new bugs for suspected defects).
