top, fixed buffer length in utils.c

[Erich Dollansky]

Hi,

On Sun, 01 Feb 2015 14:14:22 +0100
Michelle Sullivan <michelle at sorbs.net> wrote:

> Paul Koch wrote:
> > On Sun, 1 Feb 2015 17:51:59 +0800
> > Erich Dollansky <erichsfreebsdlist at alogt.com> wrote:
> >
> >   
> >> Hi,
> >>
> >> I came across this here in utils.c which is part of top:
> >>
> >>
> >> /*
> >>  * How do we know that 16 will suffice?
> >>  * Because the biggest number that we
> >>   will
> >>  * ever convert will be 2^32-1, which
> >>  is 10
> >>  * digits.
> >> */
> >>
> >> char *itoa(val)
> >>
> >> register int val;
> >>
> >> int can be 64 bits on a amd64 machine. Why is the author of this
> >> code so sure that we will never cross the 32 bit boundary?
> >>
> >> Erich
> >>     
> >
> > I thought an 'int' was a 32bit number on amd64 arch.
> >   
> 
> IIRC reading at least one of the C 'standards' (don't recall if it was
> ANSI or C99) sizeof(int) has to be determined at runtime time because
> it could be 8, or 16 bit and that wasn't dependent on the arch type,
int can be anything from 16 bits to the 'natural' size of the CPU
registers.

> it was dependent on the compiler (and maybe other factors.)

Yes, it is a decision the the compiler supplier has to do.

> Unfortunately when I queried this with a Uni Prof as to why, I was
> told, mostly its 16 bits but you should always check if you have
> something that cares (where it matters.)
> 
It is some time ago that it was 16 bits as the standard. The standard
just says that int is not shorter than a short int and not longer than
a long int.

Erich