On 3 Apr 2019, at 15:16, Bruce Evans <b...@optusnet.com.au> wrote: > > On Tue, 2 Apr 2019, Dimitry Andric wrote: >> Author: dim >> Date: Tue Apr 2 18:01:54 2019 >> New Revision: 345807 >> URL: https://svnweb.freebsd.org/changeset/base/345807 >> >> Log: >> Fix regression in top(1) after r344381, causing informational messages >> to no longer be displayed. This was because the reimplementation of >> setup_buffer() did not copy the previous contents into any reallocated >> buffer. ... > Looks like realloc() hasn't been invented yet. > > realloc() wouldn't clear the new part of the buffer, so a memset() or at > least setting the first byte in a new buffer (starting with buffer == NULL > might be needed).
Yeah, I found that a bit ugly, so just using calloc (like the previous implementation of setup_buffer did) and copying only the old contents seemed nicer. I never liked realloc's interface. > The above has some bugs when the new buffer is smaller the old buffer: > - when old_len < len - 1, the new buffer has no space for the old buffer > including its NUL terminator, so the new buffer is left unterminated > after blind truncation No, in this case the old buffer can be copied entirely, and the new buffer will already be NUL terminated, because calloc has filled the entirety of it with zeroes. This is also expected in the rest of the display.c code. > - when old_len == len - 1, the new buffer has no space for the NUL > terminator, so the new buffer is left unterminated after not overrunning > it by copying the NUL terminator No, in this case the old buffer can be copied entirely, and the new buffer will have exactly one zero byte at the end. > - when old_len > len - 1, the new buffer is NUL terminated in an obfuscated > way (calloc() has filled it with NULs and the memcpy() doesn't overwrite > them all). Indeed, that is exactly the intent. -Dimitry
signature.asc
Description: Message signed with OpenPGP