Re: Handle strncpy in tree-ssa-dse.c

[Jeff Law <law@redhat.com>]

On 7/22/19 9:40 AM, Martin Sebor wrote:
>> Given that they're not allowed to overlap, I would think not.  If that
>> were allowed then the code which aggressively transforms strncpy to
>> memcpy would need to be disabled (or at least throttled back) as well.
> 
> I think there's some (maybe too much) room for interpretation here
> as to exactly what the sentence
> 
>   If copying takes place between objects that overlap, the behavior
>   is undefined.
> 
> means.  Taken to an extreme, one might say that the following
> violates the requirement:
> 
>   char a[4] = "123\0";
>   strcpy (a, a + 2);
> 
> because the call copies bytes within the same object (the array a)
> which inevitably overlaps itself.  But I'm pretty sure that's not
> the intended  interpretation -- the object itself does overlap but
> not the bytes that are copied.  (This is also the view -Wrestrict
> takes.)  If it were undefined, then so would be the following:
> 
>   memcpy (a, a + 2, 2);
> 
> With that in mind, I would be inclined to expect the following not
> to violate the requirement either:
> 
>   strncpy (a, a + 2, 4);
> 
> because the bytes that are copied do not overlap.  With a set to
> "123\0" as done above it's equivalent to:
> 
>   memcpy (a, a + 2, 2);
>   memset (a + 2, 0, 2);
> 
> Admittedly, the examples aren't exactly the same which makes this
> question interesting.  Is it worth raising an interpretation request
> with WG14?
Hmm, I'd tend to go with the more conservative interpretation.  ie,
something like your first example is OK since there is no overlap
between the two regions accessed within the array.

If I confused things by dismissing Richi's example too quickly, then I
apologize.

Can't hurt to get clarification though.

Jeff