[Bug middle-end/88059] Spurious stringop-overflow warning with strlen, malloc and strncpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88059 Martin Sebor changed: What|Removed |Added Assignee|msebor at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW CC|msebor at gcc dot gnu.org | --- Comment #7 from Martin Sebor --- I'm no longer working on this.
[Bug middle-end/88059] Spurious stringop-overflow warning with strlen, malloc and strncpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88059 --- Comment #6 from Rangel Moreira Fischer --- When Compiler Optimization Level: Debug(-Og). Compile OK. When Compiler Optimization Level: Optimize for performance(-O2). Compile Error.
[Bug middle-end/88059] Spurious stringop-overflow warning with strlen, malloc and strncpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88059 --- Comment #5 from Rangel Moreira Fischer --- I am using esp-idf sdk. I think gcc version is 8.4.0.
[Bug middle-end/88059] Spurious stringop-overflow warning with strlen, malloc and strncpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88059
Rangel Moreira Fischer changed:
What|Removed |Added
CC||rangel_fischer at yahoo dot
com.br
--- Comment #4 from Rangel Moreira Fischer
---
Same problem too.
static void write_my_message( char* message, size_t max_message_size, char*
my_message )
{
size_t messag_len = strlen(my_message) + 1;
if( messag_len > max_message_size )
{
// trunc message
strncpy(message, my_message, max_message_size - 1); // ex:
max_message_size = max buf size = 50(0 to 49). 0 to 48 = 49
elements(max_message_size - 1).
message[max_message_size - 1] = '\0'; // message[50-1] = message[49] =
'\0'.
}
else
{
strncpy(message, my_message, messag_len);
}
}
In function 'write_my_message':
error: 'strncpy' specified bound depends on the length of the source argument
[-Werror=stringop-overflow=]
strncpy(message, my_message, messag_len);
^~~~
note: length computed here
size_t messag_len = strlen(my_message) + 1;
^~
[Bug middle-end/88059] Spurious stringop-overflow warning with strlen, malloc and strncpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88059 Martin Sebor 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 --- 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
[Bug middle-end/88059] Spurious stringop-overflow warning with strlen, malloc and strncpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88059
Moritz Bender changed:
What|Removed |Added
CC||molli.bender at gmail dot com
--- Comment #2 from Moritz Bender ---
I don't know whether this comment will ever be read, but I'd like to add that I
have the same problem with strncpy incorrectly getting the "warning: 'strncpy'
specified bound depends on the length of the source argument". I do believe
that this warning is wrong in the case that the destination buffer is also
dependant on the strlen of the source string.
Assume the following code:
char my_string[strlen(argv[1] - 1)];
strncpy(my_string, argv[1], strlen(argv[1]) - 5);
memcpy(_string[strlen(argv[1]) - 5], ".7z", 4);
printf("my string: %s\n", my_string);
This code will generate the mentioned warning, although I don't think it
should. I HAVE to use strlen to achieve what I want to; this is a relatively
common use case. I know I can use memcpy instead of the strncpy, but regarding
that her I'm just dealing with strings I'd rather use strncpy.
[Bug middle-end/88059] Spurious stringop-overflow warning with strlen, malloc and strncpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88059 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Martin Sebor --- The warning is by design. Quoting a comment from the code, it "triggers for LEN arguments that in any meaningful way depend on strlen(SRC)." The warning in these cases is designed to detect the following anti-pattern: strncpy (dest, src, strlen (src)); The code in the test case in comment #0 happens to be safe but calling strncpy in this instance is not the intended use of the API: when the size of the destination is known to be sufficient for the copy, the strcpy function is more appropriate. It might be possible to avoid the warning for a subset of these safe cases by trying to also determine whether DEST depends on LEN in the same way as LEN depends on SRC but in light of the above it doesn't seem worth the effort.
