[PATCH] set range for strlen(array) to avoid spurious -Wstringop-overflow (PR 83373 , PR 78450)

[Martin Sebor]

On 12/14/2017 03:43 AM, Richard Biener wrote:
> On Wed, Dec 13, 2017 at 4:47 AM, Martin Sebor <msebor@gmail.com> wrote:
>> On 12/12/2017 05:35 PM, Jeff Law wrote:
>>>
>>> On 12/12/2017 01:15 PM, Martin Sebor wrote:
>>>>
>>>> Bug 83373 - False positive reported by -Wstringop-overflow, is
>>>> another example of warning triggered by a missed optimization
>>>> opportunity, this time in the strlen pass.  The optimization
>>>> is discussed in pr78450 - strlen(s) return value can be assumed
>>>> to be less than the size of s.  The gist of it is that the result
>>>> of strlen(array) can be assumed to be less than the size of
>>>> the array (except in the corner case of last struct members).
>>>>
>>>> To avoid the false positive the attached patch adds this
>>>> optimization to the strlen pass.  Although the patch passes
>>>> bootstrap and regression tests for all front-ends I'm not sure
>>>> the way it determines the upper bound of the range is 100%
>>>> correct for languages with arrays with a non-zero lower bound.
>>>> Maybe it's just not as tight as it could be.
>>>
>>> What about something hideous like
>>>
>>> struct fu {
>>>   char x1[10];
>>>   char x2[10];
>>>   int avoid_trailing_array;
>>> }
>>>
>>> Where objects stored in x1 are not null terminated.  Are we in the realm
>>> of undefined behavior at that point (I hope so)?
>>
>>
>> Yes, this is undefined.  Pointer arithmetic (either direct or
>> via standard library functions) is only defined for pointers
>> to the same object or subobject.  So even something like
>>
>>  memcpy (pfu->x1, pfu->x1 + 10, 10);
>>
>> is undefined.
>
> There's nothing undefined here - computing the pointer pointing
> to one-after-the-last element of an array is valid (you are just
> not allowed to dereference it).

Right, and memcpy dereferences it, so it's undefined.

Martin