From owner-freebsd-stable@FreeBSD.ORG Tue Feb 17 22:39:44 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 EC0FFB9F for ; Tue, 17 Feb 2015 22:39:44 +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 C46B4F3B for ; Tue, 17 Feb 2015 22:39:44 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id BAB5BB939; Tue, 17 Feb 2015 17:39:43 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Subject: Re: top, fixed buffer length in utils.c Date: Tue, 17 Feb 2015 16:57:07 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <20150201175159.7fa88d16@B85M-HD3-0.alogt.com> <20150216035636.GA80472@neutralgood.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201502171657.07538.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 17 Feb 2015 17:39:43 -0500 (EST) Cc: Brandon Allbery , kpneal@pobox.com 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: Tue, 17 Feb 2015 22:39:45 -0000 On Sunday, February 15, 2015 11:18:54 pm Brandon Allbery wrote: > On Sun, Feb 15, 2015 at 10:56 PM, wrote: > > > There > > will _never_ be a compiler of anything resembling popularity for any > > established FreeBSD host that has int as anything other than 32 bits in > > size. > > > > This is optimistic beyond sanity, based on history. I was making a point as > well.... Really. People claimed this in the 16-bit days, because the idea > of something using 32 bits was obviously going to break things and be too > difficult to cope with. So where are we now? > > There will be 64-bit CPUs, as opposed to 32-bit CPUs with 64-bit > extensions, in the future. Be certain of this. (Heck, there's already been > one, albeit not popular: DEC Alpha.) And eventually (unlike the Alpha) the > native word size will be used as the default word size because people --- > specifically, developers --- will want that. Which means (int) will change. > > The only constant in the world is change. You can choose to change with it, > or to pretend that it doesn't/didn't happen. The latter just means you'll > be left in the dust wondering why the world isn't paying any attention to > you any more. I'm not advocating that ints will forever be 64-bits, but I think it will probably be quite a while. If anything, the trend on 64-bit platforms is the opposite due to 64-bits being too wasteful for longs and pointers (see x32 for x86 and mipsn32). -- John Baldwin