https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84468

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2018-02-19
                 CC|                            |msebor at gcc dot gnu.org
          Component|c++                         |tree-optimization
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=84470
     Ever confirmed|0                           |1

--- Comment #2 from Martin Sebor <msebor at gcc dot gnu.org> ---
The warning is designed to look at the next statement just after a call to
strncpy() and if it's an assignment to the destination it does not trigger. 
Unfortunately, due to a limitation/missing feature in the optimizer (bug
84470), in the test case in comment #0, the 'if (iCString)' test prevents the
warning from seeing that the next statement is an assignment.

As you already noted, making the assignment to _cstring[3] in A::setCString()
also conditional on iCString being nonnull avoids the warning.  This will
become unnecessary once the missing optimization mentioned in bug 84470 is
implemented.  I can confirm that the warning is a false positive in this case. 
Let me see if there's a way to enhance the warning to handle it until the
optimization is implemented.

(In reply to Sérgio Basto from comment #1)
> btw and this warning  [1] make sense ? 
> 
> [1]
> mongoose.c: In function 'mg_resolve_async_opt':
> mongoose.c:10791:3: error: 'strncpy' specified bound 1024 equals destination
> size [-Werror=stringop-truncation]
>    strncpy(req->name, name, sizeof(req->name));

It's a common mistake to assume that strncpy() nul-terminates the copy even
when it's called with the size of the destination as the last argument and a
source at least as long.  The warning is meant to detect cases when this
assumption may be unsafe.  It tries to avoid triggering for provably safe code
(by looking for the subsequent assignment, or by tracking string lengths when
it can) but the logic isn't perfect so it's best to call the function with a
byte count that's less than the destination size and follow the call
immediately by an assignment of the nul to the destination.

Reply via email to