Date: Sun, 01 Feb 2015 14:14:22 +0100 From: Michelle Sullivan <michelle@sorbs.net> To: Paul Koch <paul.koch@akips.com> Cc: freebsd-stable@freebsd.org Subject: Re: top, fixed buffer length in utils.c Message-ID: <54CE26AE.10005@sorbs.net> In-Reply-To: <20150201195722.68845794@akips.com> References: <20150201175159.7fa88d16@B85M-HD3-0.alogt.com> <20150201195722.68845794@akips.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Paul Koch wrote: > On Sun, 1 Feb 2015 17:51:59 +0800 > Erich Dollansky <erichsfreebsdlist@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, it was dependent on the compiler (and maybe other factors.) 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.) -- Michelle Sullivan http://www.mhix.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54CE26AE.10005>