Re: PATCH: utils.c: Fix use of uninitialized memory in metafy().

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

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
} caller.

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.