From owner-freebsd-stable@FreeBSD.ORG Thu Feb 12 23:21:48 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 69AC7B1D for ; Thu, 12 Feb 2015 23:21:48 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3E41EC8A for ; Thu, 12 Feb 2015 23:21:47 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t1CNLjsB081431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Feb 2015 15:21:45 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t1CNLjDX081430; Thu, 12 Feb 2015 15:21:45 -0800 (PST) (envelope-from jmg) Date: Thu, 12 Feb 2015 15:21:45 -0800 From: John-Mark Gurney To: Erich Dollansky Subject: Re: top, fixed buffer length in utils.c Message-ID: <20150212232145.GG1953@funkthat.com> References: <20150201175159.7fa88d16@B85M-HD3-0.alogt.com> <20150203003307.GG27103@funkthat.com> <20150210231440.GB471@rancor.immure.com> <20150212091323.245485ba@B85M-HD3-0.alogt.com> <20150212043321.GD840@rancor.immure.com> <20150212052058.GB77578@neutralgood.org> <20150212180231.737ea2ba@B85M-HD3-0.alogt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150212180231.737ea2ba@B85M-HD3-0.alogt.com> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Thu, 12 Feb 2015 15:21:45 -0800 (PST) Cc: freebsd-stable@freebsd.org, 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: Thu, 12 Feb 2015 23:21:48 -0000 Erich Dollansky wrote this message on Thu, Feb 12, 2015 at 18:02 +0800: > On Thu, 12 Feb 2015 00:20:58 -0500 > kpneal@pobox.com wrote: > > > On Wed, Feb 11, 2015 at 10:33:21PM -0600, Bob Willcox wrote: > > > On Thu, Feb 12, 2015 at 09:13:23AM +0800, Erich Dollansky wrote: > > > > On Tue, 10 Feb 2015 17:14:41 -0600 > > > > Bob Willcox wrote: > > > > > On Mon, Feb 02, 2015 at 04:33:07PM -0800, John-Mark Gurney > > > > > wrote: > > > > > > Erich Dollansky wrote this message on Sun, Feb 01, 2015 at > > > > > > 17:51 +0800: > > > > If you want, just read the old discussion regarding time_t. > > > > > > Oh, I've been around since ints were 8 bits (on really old stuff) > > > and appreciate the issues. However my point wasn't that assuming > > > the size is good, but that when ints change we will have lots more > > > serious breakage is all. > > > > But time_t is not a fundamental type. So time_t changing size is much > > less of an issue than int changing size. > > > time_t was introduced some time to avoid the problem of changing data > sizes. Wasn't time of the type long before and wasn't it assumed to be > 32 bit? Sadly, it looks like we may have to introduce a new i386 "platform"/ABI in order to deal w/ the fact that time_t is only 32bits to address the 2038 problem.. > > If int changed size we'd need a new type to replace it. Otherwise it'd > > be darn near impossible to access memory in 32 byte chunks in anything > > resembling a natural way. > > > I think the original idea behind data types like int or long is that > the compiler should use what seems the best fit for a machine. If the > program needs a given size, the programmer should use something like > int32 etc to avoid all problems when compilers change. It wasn't till C99 that int32_t and friends were standardized... So, lots of programming was done long before sized types were standard... Before then people were rolling their own, or simply assuming the sizes... Though as standards go, Microsoft still refeses to add these standard types, causing all sorts of problems.. > > And I submit that the days of int changing with the compiler are long > > past. It causes too much havoc. The Amiga had two different sizes of > > int based on the two major vendor compilers, and when Commodore > > ported the BSD sockets API they had to change all ints to longs. > > > > Just look at how many POSIX APIs use ints. If int were to change with > > the compiler, and so different compilers on the same target were > > different, then _every_ _single_ int used by POSIX would need to be > > changed. > > You think a bot too much of staying on the same platform. FreeBSD runs > on several platforms. As a consequence, int can be of different size > and the POSIX API will not cause a problem. I don't know of any int size other than 32bit for all supported FreeBSD platforms.. All platforms are either ILP32 or LP64 as far as I know.. > > Who thinks that's likely? > > > > Why on Earth would any vendor do something so costly? And why would > > the rest of the standards bodies (including POSIX) go along with it? > > > What says POSIX about the size of int? POSIX just follows the size the > compiler uses on a platform. > > > No, when the day int changes size comes it will be due to computers > > being changed in some way that is so fundamental that we may not even > > recognize it as a computer. Perhaps it will be organic, or perhaps it > > will be a quantum computer. > > > > Can we please put this issue to rest already? > > Hopefully. Just adding color/history... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."