> On Feb 28, 2023, at 12:49 PM, Jakub Jelinek <ja...@redhat.com> wrote:
>
> On Tue, Feb 28, 2023 at 04:13:28PM +0000, Qing Zhao wrote:
>>> On Feb 28, 2023, at 3:26 AM, Jakub Jelinek via Gcc-patches
>>> <gcc-patches@gcc.gnu.org> wrote:
>>> I think -fstrict-flex-arrays* options can be considered as language
>>> mode changing options, by default flexible member-like arrays are
>>> handled like flexible arrays, but that option can change the set of
>>> the arrays which are treated like that. So, -fsanitize=bounds should
>>> change with that on what is considered acceptable and what isn't.
>>> While -fsanitize=bounds-strict should reject them all always to
>>> continue previous behavior.
>>
>>
>> As my understanding, without your current patch, the current
>> -fsanitize=bounds-strict behaves like -fstrict-flex-arrays=2, i.e:
>> it treats:
>> [], [0] as flexible array members;
>> but
>> [1], [4] as regular arrays
>
> Yes, but not because it would be an intention, but because of a bug
> it actually never instrumented [0] arrays.
Understood.
So, your patch fixed this bug, and then [0] arrays are instrumented by default
with this patch.
> Well, it would complain about
> struct S { int a; int b[0]; int c; } s;
> ... &s.b[1] ...
> for C++, but not for C.
A little confused here: [0] arrays were instrumented by default for C++ if it’s
not a trailing array, but not for C?
>
>> Then with your current patch, [0] will NOT be treated as flexible array
>> members by default anymore, so, the -fsanitize=bounds-strict will
>> treats:
>> [] as flexible array members;
>> but
>> [0], [1], [4] as regular arrays
>> The same behavior as -fstrict-flex-arrays=3.
>>
>> Therefore, -fsanitize=bounds-strict already implies -fstrict-flex-arrays=3.
>
> No. -fsanitize=bounds-strict doesn't imply anything for
> flag_strict_flex_arrays, it for the bounds sanitization decisions
> behaves as if -fstrict-flex-arrays=3.
Yes, that was what I meant. -:)
>
>> For [0] arrays, why C++ and C represent with different IR?
>
> I think it is a historic difference that could take quite a big amount of
> work to get rid of (and the question is what is better), and even after that
> work there would be still big chances of regressions.
Okay, I see… (this is really a confusion situation…) but anyway…
Thanks.
Qing
>
> Jakub
>
