top, fixed buffer length in utils.c

[Erich Dollansky]

Hi,

On Sun, 1 Feb 2015 21:37:09 -0500
kpneal at pobox.com wrote:

> On Sun, Feb 01, 2015 at 09:11:25PM +0800, Erich Dollansky wrote:
> > the problem is that top is not a x86 only program but should work on
> > all platforms. Leaving this like it is might will cause problems
> > when int becomes more than 32 bits wide.
> > 
> > Of course, if it is known that the value to be converted will
> > always be within 32 bits, it is not a problem to do it as it is
> > done.
> 
> Isn't it a bit early to be preparing for 128-bit processors?
> 
aren't 64 bit sufficient to cause a problem?

> And, even on an LP128 processor, the emerging _int128 type should be
> sufficient to prevent int from having to grow larger than 32 bits.
> 
> Seriously, int is 32 bits in size and there is no problem with
> assuming this is true. If you like, int can be replaced with int32_t.
> Then when LP256 processors are invented long after we're all dead the
> code will still be working.
> 
C does not define int to be 32 bits in width. It just happens that the
compilers in use prefer 32 bits.

I just prefer in my own code to be on the safe side. A small change
here would help in case of.

Erich