[Bug c/77690] -Wformat-length %s false positive after strlen check

2016-10-03 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77690

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=77708
 Resolution|FIXED   |INVALID

[Bug c/77690] -Wformat-length %s false positive after strlen check

2016-09-23 Thread nsz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77690

nsz at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #5 from nsz at gcc dot gnu.org ---
(In reply to Martin Sebor from comment #4)
> Note that with snprintf GCC issues
> 
>   warning: ā€˜%sā€™ directive output may be truncated writing between 1 and 11
> bytes into a region of size 5
> 
> This is also by design though I'm on the fence about warning at the same
> level or under the same option as for sprintf.
> 

i opened another bug about snprintf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77708

i think warning for snprintf is almost surely a false positive, that is hard to
suppress (and the suppression code is not idiomatic).

[Bug c/77690] -Wformat-length %s false positive after strlen check

2016-09-23 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77690

Martin Sebor  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

--- Comment #4 from Martin Sebor  ---
Note that with snprintf GCC issues

  warning: ā€˜%sā€™ directive output may be truncated writing between 1 and 11
bytes into a region of size 5

This is also by design though I'm on the fence about warning at the same level
or under the same option as for sprintf.

FWIW, I wouldn't expect the parsing of the precision within the format string
to have a noticeable performance impact on the overall cost of the call to the
function.  If you prefer to avoid it, you can specify via an argument to the
'*':

  sprintf(foo, "zz%.*s", 4, s.buf);

I'm changing the resolution of this bug to invalid since we haven't actually
fixed anything, but if none of the solutions above is sufficient please feel
free to reopen the bug and let us know what would be (keeping in mind that the
ideal solution of tracking the actual string length or its range or determining
it from the strlen call may not be feasible in the near term).

[Bug c/77690] -Wformat-length %s false positive after strlen check

2016-09-23 Thread nsz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77690

nsz at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from nsz at gcc dot gnu.org ---
(In reply to nsz from comment #2)
> in my case truncation is fatal error so using precision is not useful (other
> than suppressing the warning) and has a runtime cost (extra arg passing for
> %.*s).

nevermind, i'll just use snprintf.

[Bug c/77690] -Wformat-length %s false positive after strlen check

2016-09-23 Thread nsz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77690

--- Comment #2 from nsz at gcc dot gnu.org ---
(In reply to Martin Sebor from comment #1)
>   sprintf(foo, "zz%.4s", s.buf);
> 
> Please let me know if this isn't sufficient to resolve the problem report.

in my case truncation is fatal error so using precision is not useful (other
than suppressing the warning) and has a runtime cost (extra arg passing for
%.*s).

[Bug c/77690] -Wformat-length %s false positive after strlen check

2016-09-22 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77690

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-09-23
 CC||msebor at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1
  Known to fail||7.0

--- Comment #1 from Martin Sebor  ---
Unfortunately, even though it seems like the if statement with the strlen call
should help, the length range information isn't available to the warning pass. 
The warning can, however, be avoided by constraining the length of the string
argument output by specifying the precision in the directive like so:

  sprintf(foo, "zz%.4s", s.buf);

Please let me know if this isn't sufficient to resolve the problem report.