[Bug middle-end/78174] out of bounds array subscript in rtl.h NOTE_DATA macro

jakub at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Tue Nov 1 16:45:00 GMT 2016


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78174

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Martin Sebor from comment #6)
> (In reply to Jakub Jelinek from comment #5)
> 
> Do you have an explanation of why it's "just incorrect?" or an example where
> it results in warning on valid code?

Only -D_FORTIFY_SOURCE=1 which always uses __bos (, 0) is fully complaint mode,
-D_FORTIFY_SOURCE=2 is a mode that imposes additional restrictions (both that
%n in *printf family can't be used in writable format strings and that
str*/stp* functions can't cross field boundaries.
Doing memset (field_address, 0, sizeof (whole_struct) - offsetof (struct,
field)); and similar is just so common that breaking it is not desirable even
in that extra mode.  As in the warning you want to add (which I'm still not
very happy about, because the important distinction where you just warn about
something that may happen or not vs. warning where you warn that if you execute
this particular code path, you'll always __chk_fail () and abort the process is
lost, plus there is no separate option or warning levels for those must fail
and "must invoke UB" and "may invoke UB") doesn't know if the additional
restrictions are imposed or not, except when __builtin_*_chk builtins are used,
IMNSHO you should use __bos (, 0) for all those other cases.

It is true that ideally we'd use flexible array members for u.fld, except that
C++ doesn't have them, and somebody decided it is a good idea to wrap them into
further classes.  I know coverity is unhappy about that, perhaps a way out of
this would be to just always use fld[10]; or whatever is the highest number of
RTL operands (similarly for tree_exp).  But that doesn't change anything on
that this is a very common technique used by tons of other programs and we do
not want to warn about that.


More information about the Gcc-bugs mailing list