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. Well, it would complain about
struct S { int a; int b[0]; int c; } s;
... &s.b[1] ...
for C++, 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.
> 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.
Jakub
