Оля Тележная <[email protected]> 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 ;-)
