Date: Wed, 3 Apr 2019 21:42:59 +0200 From: Dimitry Andric <dim@FreeBSD.org> To: Bruce Evans <brde@optusnet.com.au> Cc: src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r345807 - head/usr.bin/top Message-ID: <C56E36CA-1289-4074-8748-48326B2D4CD1@FreeBSD.org> In-Reply-To: <20190403234558.X1970@besplex.bde.org> References: <201904021801.x32I1sxX019439@repo.freebsd.org> <20190403234558.X1970@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_5733E18B-193D-4A27-B386-DDD252477B54 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 3 Apr 2019, at 15:16, Bruce Evans <brde@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 --Apple-Mail=_5733E18B-193D-4A27-B386-DDD252477B54 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCXKUMwwAKCRCwXqMKLiCW o5KgAJsHYRWGvsFCC9jmrS4ylTKqCR7Z8gCdGcjmXMW6sJIuQMwjUD0KPg0y9BY= =+1zd -----END PGP SIGNATURE----- --Apple-Mail=_5733E18B-193D-4A27-B386-DDD252477B54--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C56E36CA-1289-4074-8748-48326B2D4CD1>