[Bug c/82296] Warn for code removal due to "code never accesses array out of bounds" assumption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82296 Krister Walfridsson changed: What|Removed |Added CC||kristerw at gcc dot gnu.org --- Comment #7 from Krister Walfridsson --- The C89 rules are the same as for C11 -- you can find the relevant text in C90 6.3.6 (it does not cover the "UB 62" from the ARR30-C page, but that is because C89 does not have flexible array members...) Using -std=c89 will compile following the rules in C89, so you will not suffer from new undefined behaviors introduced in newer standards.
[Bug c/82296] Warn for code removal due to "code never accesses array out of bounds" assumption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82296 --- Comment #6 from Ingo --- > https://www.securecoding.cert.org/confluence/display/c/ARR30-C.+Do+not+form+or+use+out-of-bounds+pointers+or+array+subscripts Just out of curiosity: I am not able to find any of that in the ANSI/ISO C89 standard. That might be, because I am not familiar where to find that in the C89 standard (I am definitely not familiar with any of the formal C standard documents). I also noticed that if I compile the example with gcc -std=c89 -O2 -S gcc_check.c I also get assembler code which basically implements "return 1;". So does that mean gcc will always define "undefined behavior" according to the C-2011 standard, even if you use "-std=c89" ? What happens when the standard committee release a more recent version of the C standard ? Will the upcoming versions of GCC then use the updated definitions of "undefined behavior" from the upcoming C standards definition and thus produce non working code for any source code, which was not able to look into the future and guessing what the C standards committee might deem "undefined behavior" in the future ?
[Bug c/82296] Warn for code removal due to "code never accesses array out of bounds" assumption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82296 --- Comment #5 from Thomas Koenig --- Also see https://www.securecoding.cert.org/confluence/display/c/ARR30-C.+Do+not+form+or+use+out-of-bounds+pointers+or+array+subscripts
[Bug c/82296] Warn for code removal due to "code never accesses array out of bounds" assumption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82296 Markus Trippelsdorf changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #4 from Markus Trippelsdorf --- (In reply to Ingo from comment #3) > And just because there is this paragraph in the C language specification, > the compiler is then allowed to produce "random" code ? Yes. The compiler assumes that undefined behavior is never invoked and optimizes accordingly. This is nothing new. If you need hand-holding use the sanitizers.
[Bug c/82296] Warn for code removal due to "code never accesses array out of bounds" assumption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82296 --- Comment #3 from Ingo --- Just to be sure: On a real machine this code is certainly not "undefined behavior", because gMyUnion.numbers[ARRAYSIZE] aliases gMyUnion.dummy[ARRAYSIZE] and gMyUnion.dummy[ARRAYSIZE] is a valid memory location. So I guess there somewhere is a paragraph in the C language specification, which says "this is undefined behavior", even if declaring this "undefined" probably contradicts the semantics of unions and pointer arithmetic (specified in the same said C language specification). And just because there is this paragraph in the C language specification, the compiler is then allowed to produce "random" code ?
[Bug c/82296] Warn for code removal due to "code never accesses array out of bounds" assumption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82296 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |INVALID --- Comment #2 from Jakub Jelinek --- We have a warning that handles the easiest counted loops, for anything else the warning is too hard (could produce too many false positives). Just use -fsanitize=undefined or other runtime instrumentation to find such bugs.
