On 02/26/2018 05:08 AM, Richard Biener wrote:
> On Fri, Feb 16, 2018 at 8:07 PM, Martin Sebor <mse...@gmail.com> wrote:
>> Say I have a struct like this:
>>
>> struct A {
>> char a[4], b[5];
>> };
>>
>> then in
>>
>> extern struct A *a;
>>
>> memset (&a[0].a[0] + 14, 0, 3); // invalid
>>
>> memset (&a[1].b[0] + 1, 0, 3); // valid
>>
>> both references are the same:
>>
>> &MEM_REF[char*, (void *)a + 14];
>>
>> and there's no way to unambiguously tell which member each refers
>> to, or even to distinguish the valid one from the other. MEM_REF
>> makes the kind of analysis I'm interested in very difficult (or
>> impossible) to do reliably.
>
> Yes. Similar issues exist for the objsz pass (aka fortify stuff).
In fact, I think we have a long standing regression in this space.
>
>> Being able to determine the member is useful in -Wrestrict where
>> rather than printing the offsets from the base object I'd like
>> to be able to print the offsets relative to the referenced
>> member. Beyond -Wrestrict, identifying the member is key in
>> detecting writes that span multiple members (e.g., strcpy).
>> Those could (for example) overwrite a member that's a pointer
>> to a function and cause code injection. As it is, GCC has no
>> way to do that because __builtin_object_size considers the
>> size of the entire enclosing object, not that of the member.
>> For the same reason: MEM_REF makes it impossible.
>
> We're first and foremost an optimizing compiler and not a
> static analysis tool. People seem to want some optimization
> to make static analysis easier but then they have to live with
> imperfect results. There's no easy way around this kind of
> issues.
True, but there is significant value in generating good diagnostics.
IMHO it's worth thinking about if/how we can get the refinements we want
on the diagnostic side without regressing on the code generation side.
jeff
