Date: Mon, 2 Feb 2015 14:31:53 +0800 From: Erich Dollansky <erichsfreebsdlist@alogt.com> To: kpneal@pobox.com Cc: freebsd-stable@freebsd.org Subject: Re: top, fixed buffer length in utils.c Message-ID: <20150202143153.51638086@B85M-HD3-0.alogt.com> In-Reply-To: <20150202023709.GA28422@neutralgood.org> References: <20150201175159.7fa88d16@B85M-HD3-0.alogt.com> <20150201195722.68845794@akips.com> <20150201211125.2fb21c39@B85M-HD3-0.alogt.com> <20150202023709.GA28422@neutralgood.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, On Sun, 1 Feb 2015 21:37:09 -0500 kpneal@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150202143153.51638086>