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.
