https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618
--- Comment #6 from Daniel Gutson <daniel.gutson at tallertechnologies dot com> --- (In reply to Andrew Pinski from comment #5) > (In reply to Daniel Gutson from comment #4) > > (In reply to Andreas Schwab from comment #3) > > > Trying to read the (uninitialized) contents of the allocated memory for x > > > <= > > > 12 would be undefined behaviour, so calling calloc instead does not change > > > the defined behaviour. > > > > Why do you assert that the program will read the memory? > > It does not. It just optimizes the code. I meant: how do you know what the program will do next? Maybe it will write memory. See below please. > > > The optimization ignores the 'if' statement (just comment that line and > > see), so if malloc() returns NULL, memset is called unconditionally and will > > try to write to address NULL. The "x > 12" was just an example that this is > > arbitrary. Replace it with something else. The 'if' shall not be ignored. > > yes that just undefined behavior when invoking memset with a NULL value, so > replacing it is still fine. That's why the 'if (ptr != NULL)' should not be ignored, which currently is. The 'if' prevents the UB. > > Also calloc is sometimes faster than a malloc/memset due to knowing if the > kernel will zero out the memory, etc. This is not under discussion.
