https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88059
Martin Sebor <msebor at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |ASSIGNED
Last reconfirmed|2018-11-16 00:00:00 |2019-07-02
Blocks| |83819
Resolution|WONTFIX |---
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #3 from Martin Sebor <msebor at gcc dot gnu.org> ---
The warning isn't wrong -- the strncpy bound does depend on the length of the
source argument. But I agree that it isn't helpful. As I mentioned in comment
#1 there may be a way to avoid it in a subset of instances but it requires some
non-trivial changes. At a minimum these come to mind:
1) track the size of the memory allocated either by malloc or alloca/VLAs
2) look at the next statement to see if it appends the terminating nul without
assuming the strncpy call itself appended it
That said, (2) already exists, albeit to a limited extent, so it needs to be
extended to other places. (1) would be useful for many other things (e.g.,
detection of heap buffer overflow or reading from uninitialized heap memory).
It's something I'm already planning to work on in any case, so I'll see if I
can deal with this as well.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819
[Bug 83819] [meta-bug] missing strlen optimizations
