Date: Thu, 12 Feb 2015 18:02:31 +0800 From: Erich Dollansky <erichsfreebsdlist@alogt.com> To: kpneal@pobox.com Cc: John-Mark Gurney <jmg@funkthat.com>, freebsd-stable@freebsd.org Subject: Re: top, fixed buffer length in utils.c Message-ID: <20150212180231.737ea2ba@B85M-HD3-0.alogt.com> In-Reply-To: <20150212052058.GB77578@neutralgood.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, 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 <bob@immure.com> 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? > 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. > 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. > > 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. Erich
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150212180231.737ea2ba>