Zsh Mailing List Archive
Messages sorted by:
Re: PATCH: utils.c: Fix use of uninitialized memory in metafy().
On Nov 27, 8:26pm, Peter Stephenson wrote:
} Subject: Re: PATCH: utils.c: Fix use of uninitialized memory in metafy().
} On Wed, 27 Nov 2013 10:54:09 -0800
} Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
} > On Nov 27, 6:07pm, Peter Stephenson wrote:
} > }
} > } .... So if we've got only len valid bytes, not
} > } null-terminated (or null-terminated by accident because the next byte
} > } that isn't actually valid for the allocation happens to be null), we've
} > } got no way of knowing this given the current interface.
} > Does it actually matter? The only reason for (*e != 0) as far as I can
} > tell is to be sure we've actually done (*e = '\0') at the very end of
} > the whole thing [comment: "... unchanged (a terminating null character
} > is appended to buf if necessary)"].
} > Can't we just move the *e = '\0' outside the "if" body and skip the test
} > in the condition?
} Seems reasonable --- it requires the problem Simon was seeing to be in a
} case that's requesting reallocation, else that assignment is going to
} cause problems, but if it does cause problems we need to change the
No, the problem Simon was seeing must in fact occur only in cases that
have no metacharacters and are NOT requesting reallocation, otherwise
the short-circuiting behavior of logical-or would never get as far as
testing (*e != '\0').
But (in the current code) if the test succeeds, then we enter the block
and execute *e = '\0', and if the test fails then *e == '\0' must be
true. The only case in which assigning '\0' could be a (new) problem is
one where the byte at buf[len] is already zero but is somehow in a part
of memory to which we aren't allowed to write.
Or where (len > 0 && *e && e != buf+len) but I don't see how that could
happen either. We could throw in a DPUTS if you are worried.
Simon's valgrind report wasn't a pointer out-of-bounds error, it was an
uninitialized memory error.
Messages sorted by: