[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: report a warning
From: |
Hans-Bernhard Bröker |
Subject: |
Re: report a warning |
Date: |
Mon, 9 Jan 2023 20:39:44 +0100 |
User-agent: |
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 |
Am 09.01.2023 um 19:58 schrieb Gavin Smith:
As I said in another message, it appears that everywhere strncat is
used, the length argument is used for the number of bytes to copy in
the source buffer, not for the size remaining in the destination buffer.
And that is at least superficially wrong every time.
Which is why it triggers a warning, if the compiler manages to detect
this coding pattern.
The only cases where this is not an anti-pattern are those where the
output buffer size depends on the input string length. Telling these
cases apart can take quite bit of analysis.
Whatever the original intention was behind strncat, this seems like
a reasonable way to use strncat based on its behaviour and documentation.
It is not.
The size argument exists to enable the caller to make sure that the
destination buffer is not overrun, and for that to be possible, the size
argument _must_ have a dependency on the size of that destination
buffer. It may depend on the input string length, too, but that must
not be the only dependency.
If one's not going to do the work needed to compute the size argument
correctly, then strncat() cannot offer any benefit over strcat(), and
one might as well not bother using it.
The line that led to the compiler warning was no different to the other
uses in the program, but it was the only one the compiler flagged up.
Detecting this anti-pattern can be hard, so just because it isn't
flagged every time does not mean the other ones are correct. For all
the improvement they've made in this regard, compilers aren't
necessarily the best tools for finding this kind of weakness. Dedicated
code analysis tools still beat them at it.