Оля Тележная <olyatelezhnaya@xxxxxxxxx> writes: >> Hmph, doesn't this belong to the previous step? In other words, >> isn't the result of applying 1-3/4 has a bug that can leave eaten >> uninitialized (and base decision to free(buf) later on it), and >> isn't this change a fix for it? > > Oh. I was thinking that it was new bug created by me. Now I see that > previously we had the same problem. The original said something like: int eaten; void *buf = get_obj(..., &eaten); ... if (!eaten) free(buf); and get_obj() left eaten untouched when it returned NULL. As a random uninitialized cruft in eaten that happened to be "true" would just cause free(NULL) on many archs, there was no practical problem in such a code, but it is undefined behaviour nevertheless. And the previous step made it a bit more alarming ;-)
