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