svn commit: r345807 - head/usr.bin/top

Dimitry Andric dim at FreeBSD.org
Wed Apr 3 19:43:10 UTC 2019


On 3 Apr 2019, at 15:16, Bruce Evans <brde at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 223 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20190403/2ad73f90/attachment.sig>


More information about the svn-src-head mailing list