On Wed, Aug 01, 2018 at 09:19:43AM +0200, Richard Biener wrote:
> > And if so, what makes it well defined?
>
> The fact that strlen takes a char * argument and thus inline-expansion
> of a trivial implementation like
>
> int len = 0;
> for (; *p; ++p)
> ++len;
>
> will have
>
> p = &s.a;
>
> and the middle-end doesn't reconstruct s.a[..] from the pointer
> access.
Some testcases:
struct S { char a[3]; char b[5]; } s[3] = { { "ab", "defg" }, { "h", "klmn" },
{ "opq", "rstu" } };
__SIZE_TYPE__
foo (int i, int a)
{
volatile char *p = (volatile char *) &s[i].a;
if (a)
p = (volatile char *) &s[i];
return __builtin_strlen ((char *) p);
}
If I call this with foo (2, 1), do you still claim it is not valid C?
I don't see in C anything that would say that this is not valid for strlen,
but valid for memcpy, and if you say it is not valid even for memcpy, then
pretty much nothing will work, we need memcpy to be able to copy whole objects
containing subobjects. The middle-end optimizes the above into
p_3 = &s[i_2(D)].a;
_7 = __builtin_strlen (p_3);
(in fre3 in particular).
Or:
int bar (char *) __attribute__((pure));
int v;
__SIZE_TYPE__
baz (int i, int a)
{
int b = bar (&s[i].a[0]);
__SIZE_TYPE__ t = __builtin_strlen ((char *) &s[i]);
v = b;
return t;
}
where bar may say just int bar (char *p) { return *p; }
The middle-end optimizes this into:
_1 = &s[i_3(D)].a[0];
b_5 = bar (_1);
t_6 = __builtin_strlen (_1);
That is why for __builtin_object_size (..., [13]) where we want to
differentiate between that we need to handle it very early, because later on
the distinction is gone.
Jakub
