top, fixed buffer length in utils.c

[Erich Dollansky]

Hi,

On Thu, 12 Feb 2015 00:20:58 -0500
kpneal at 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 at 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