PING 4 [PATCH] allow more strncat calls with -Wstringop-truncation (PR 85700)

Martin Sebor msebor@gmail.com
Tue Jun 19 02:49:00 GMT 2018


Ping: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01189.html

On 06/11/2018 11:34 AM, Martin Sebor wrote:
> Ping: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01189.html
>
> On 06/04/2018 05:45 PM, Martin Sebor wrote:
>> Ping: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01189.html
>>
>> On 05/29/2018 10:19 AM, Martin Sebor wrote:
>>> Ping: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01189.html
>>>
>>> On 05/22/2018 07:40 PM, Martin Sebor wrote:
>>>> Here's another small refinement to -Wstringop-truncation to
>>>> avoid diagnosing more arguably "safe" cases of strncat() that
>>>> match the expected pattern of
>>>>
>>>>   strncat (d, s, sizeof d - strlen (d) - 1);
>>>>
>>>> such as
>>>>
>>>>   extern char a[4];
>>>>   strncat (a, "12", sizeof d - strlen (a) - 1);
>>>>
>>>> Since the bound is derived from the length of the destination
>>>> as GCC documents is the expected use, the call should probably
>>>> not be diagnosed even though truncation is possible.
>>>>
>>>> The trouble with strncat is that it specifies a single count
>>>> that can be (and has been) used to specify either the remaining
>>>> space in the destination or the maximum number of characters
>>>> to append, but not both.  It's nearly impossible to tell for
>>>> certain which the author meant, and if it's safe, hence all
>>>> this fine-tuning.  I suspect this isn't the last tweak, either.
>>>>
>>>> In any event, I'd like to commit the patch to both trunk and
>>>> gcc-8-branch.  The bug isn't marked regression but I suppose
>>>> it could (should) well be considered one.
>>>>
>>>> Martin
>>>
>>
>



More information about the Gcc-patches mailing list