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)?
jeff
