From owner-freebsd-stable@FreeBSD.ORG Wed Feb 18 15:11:47 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AD65BCC0 for ; Wed, 18 Feb 2015 15:11:47 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 84C7C613 for ; Wed, 18 Feb 2015 15:11:47 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 444D6B953; Wed, 18 Feb 2015 10:11:46 -0500 (EST) From: John Baldwin To: kpneal@pobox.com Subject: Re: top, fixed buffer length in utils.c Date: Wed, 18 Feb 2015 08:35:24 -0500 Message-ID: <3448299.k0XuYIUFXB@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: <20150218025100.GA49517@neutralgood.org> References: <20150201175159.7fa88d16@B85M-HD3-0.alogt.com> <201502171657.07538.jhb@freebsd.org> <20150218025100.GA49517@neutralgood.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 18 Feb 2015 10:11:46 -0500 (EST) Cc: freebsd-stable@freebsd.org, Brandon Allbery X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 15:11:47 -0000 On Tuesday, February 17, 2015 09:51:00 PM kpneal@pobox.com wrote: > TL;DR: we shouldn't go littering our source tree with portability crap > just to handle a case (64 bit ints) that is probably many, many years in > the future. Yeah, but I think char buf[sizeof(int) * 3 + 1] is actually less crappy than char buf[10] despite it being more portable. It is more obvious to the reader what is happening. Magic numbers are the least obvious thing to read and require more work for the reader to understand (hence needing a mult-line block comment to explain in this case). -- John Baldwin