"Paul D. Smith" <[EMAIL PROTECTED]> wrote ... > > %% Markus Mauhart <[EMAIL PROTECTED]> writes: > > mm> ... otherwise the later loop could read outside the allocated memory. > > Yes, but this can never happen because each string _must_ be > nul-terminated, and the previous invocation before the last one would > set: > > ebuf->bufnext = p+1; > > (where p points to the nul char) so ebuf->bufnext can never, really, > equal the last character in the string; it will always be one greater > than that.
Right. What IMHO is missleading for a casual reader like me is the comment /* Malloc'd size of buffer. */ in the declaration of ebuffer.bufnext, which doesnt correspond to the current usage in readstring() nor to the assignment "ebuf.size = strlen (buffer);" found in eval_buffer(); so ideally you change readline's ">" to ">=" and in eval_buffer() use "ebuf.size = 1 + strlen(buffer);". > mm> And btw, the "return 0" looks a bit surprising too. > > No, that's correct. This function is only called during an eval and > nothing should be added to the line counter during an eval. aha, sounds very reasonable. Btw, my suggested correction had a bug w.r.t. failing strchr(p,EOL): mm> eol = strchr (begin, '\n'); mm> if (eol == 0 || eol == begin || eol[-1] != '\\') break; Case "eol == 0" then would result in invalid ebuf->bufnext. Regards, Markus. _______________________________________________ Bug-make mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-make
