Re: -Wformat-truncation outputs emtpy lines instead of source

[Martin Sebor <msebor at gmail dot com>]

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