[Bug sanitizer/98609] sanitizer diagnoses VLAs with length zero although zero-length arrays are a GNU extension

2023-07-30 Thread muecker at gwdg dot de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98609

--- Comment #9 from Martin Uecker  ---

I just ran into this problem again while trying to fix PR98608 where the
problem is that instrumentation of parameters is missing.  In parameters people
often use n == 0 null and some of the -Wnonnull warnings we have currently even
require setting it 0.

[Bug sanitizer/98609] sanitizer diagnoses VLAs with length zero although zero-length arrays are a GNU extension

2021-01-11 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98609

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #8 from Martin Sebor  ---
Zero allocations should be diagnosed by -Walloc-zero.  The option is disabled
by default to avoid false positives for calls to malloc(0) emitted by GCC in
some cases.  The test case in comment #0 isn't diagnosed even when -Walloc-zero
is explicitly set is a bug.  It should be diagnosed, and I think for VLAs the
warning should be enabled in -Wall to help detect potential aliasing
violations).

Some uses of zero length arrays that aren't VLAs are diagnosed by
-Wzero-length-bounds (enabled by -Warray-bounds).  I posted a patch in November
to enhance their detection, including VLAs, but it never got reviewed.  I
expect to resubmit it for GCC 12.  With that patch, the test case in comment #0
is diagnosed as long as the array is either accessed or passed as an argument
to a function that might use it.

[Bug sanitizer/98609] sanitizer diagnoses VLAs with length zero although zero-length arrays are a GNU extension

2021-01-11 Thread marxin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98609

--- Comment #7 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #6)
> That is not really possible, as the compiler assumes for
> -fno-sanitize-recover=vla

which is not the default value/

> that when we call the library routine, it never
> returns (it is noreturn).

Then it can be allowed only for recover UBSAN entry points.

[Bug sanitizer/98609] sanitizer diagnoses VLAs with length zero although zero-length arrays are a GNU extension

2021-01-11 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98609

--- Comment #6 from Jakub Jelinek  ---
That is not really possible, as the compiler assumes for
-fno-sanitize-recover=vla that when we call the library routine, it never
returns (it is noreturn).

[Bug sanitizer/98609] sanitizer diagnoses VLAs with length zero although zero-length arrays are a GNU extension

2021-01-11 Thread marxin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98609

--- Comment #5 from Martin Liška  ---
I would recommend changing just libsanitizer to allow something like
UBSAN_OPTIONS=vla_bounds_allow_zero=1. Should be relatively small change.

[Bug sanitizer/98609] sanitizer diagnoses VLAs with length zero although zero-length arrays are a GNU extension

2021-01-11 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98609

--- Comment #4 from Jakub Jelinek  ---
I'd say it is similar with shifts, the diagnostics about the shift count being
negative or too large is highly useful, the diagnostics about the various
lshift properties shifting into sign bit or shifting left negative values etc.)
are pedantic, at least GCC doesn't really take any advantage of that, because
there are so many different variants of the restrictions.
But for shifts we indeed do have a way to selectively turn one or the other on
or off.
So perhaps -fsanitize=vla can be a union of two subooptions too.
Though, we can't really do anything about this until upstream libsanitizer is
changed, because the diagnostics comes from that library.
And it would be really confusing to just do this on the GCC side, allow
VLA checks of <= 0 (=vla), < 0 (=vla-negative), == 0 (=vla-zero) and use the
same library routine in all cases that would always talk about non-positive
value.

[Bug sanitizer/98609] sanitizer diagnoses VLAs with length zero although zero-length arrays are a GNU extension

2021-01-11 Thread muecker at gwdg dot de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98609

--- Comment #3 from Martin Uecker  ---
Fair enough. But there is also no way to selectively turn it off (or I am not
aware of it).  The warning for < 0 is important and useful while the warning
for == 0 is pedantic and not useful by itself when we generally allow zero
sized arrays elsewhere.

[Bug sanitizer/98609] sanitizer diagnoses VLAs with length zero although zero-length arrays are a GNU extension

2021-01-11 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98609

--- Comment #2 from Jakub Jelinek  ---
The sanitizers generally diagnose what the C or C++ language spec say, not what
the various extensions allow, it is the same also for shifts etc.
So I think it is correct that this is diagnosed by default.

[Bug sanitizer/98609] sanitizer diagnoses VLAs with length zero although zero-length arrays are a GNU extension

2021-01-11 Thread marxin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98609

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-01-11

--- Comment #1 from Martin Liška  ---
Confirmed.
@Marek: Can you please take a look?