https://bugs.kde.org/show_bug.cgi?id=401284
--- Comment #4 from Mark Wielaard <[email protected]> --- (In reply to AL from comment #3) > My point was that strncat() will never even encounter the terminating '\0' > byte in the source string because its counter (5) will be depleted to 0 > before then (or, in a generic case, the '\0' would have been encountered in > the source string earlier -- causing strncat() to return). Which means that > technically the pointers used in such an operation will have never crossed > the paths of each other (in this case, the source pointer will never be used > to extract anything that goes into the area where the destination pointer > was operating). Technically you are right. But I would worry about the string terminator overlap. An implementation might copy 8 bytes at a time if len == 7 (or any n * 8 - 1) . Which would have overlap. It probably would still be fine. There would probably be an explicit zero terminating byte that fixed up any overlap confusion. But it does feel you are just on the edge of what is "allowed". > I still consider that warning as excessive in the reported case. You might well be right. And I wouldn't complain if the overlap check was adjusted to just account for the maximum n chars in src. But the code as given does make warning flags go off in other tools as well. e.g. gcc 13 (didn't test with other versions) will also insist there is a possible 1 byte overlap: $ gcc -O2 -Wall -g -o vbug vbug.c vbug.c: In function ‘main’: vbug.c:10:5: warning: ‘strncat’ accessing between 1 and 9223372036854775805 bytes at offsets [0, 9223372036854775805] and 0 may overlap 1 byte at offset [0, 9223372036854775807] [-Wrestrict] 10 | strncat(buf + len, buf, len); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- You are receiving this mail because: You are watching all bug changes.
