Date: Fri, 13 Feb 2015 15:40:30 +0800 From: Erich Dollansky <erichsfreebsdlist@alogt.com> To: John-Mark Gurney <jmg@funkthat.com> Cc: freebsd-stable@freebsd.org, kpneal@pobox.com Subject: Re: top, fixed buffer length in utils.c Message-ID: <20150213154030.00a03e81@B85M-HD3-0.alogt.com> In-Reply-To: <20150212232145.GG1953@funkthat.com> References: <20150201175159.7fa88d16@B85M-HD3-0.alogt.com> <20150203003307.GG27103@funkthat.com> <20150210231440.GB471@rancor.immure.com> <20150212091323.245485ba@B85M-HD3-0.alogt.com> <20150212043321.GD840@rancor.immure.com> <20150212052058.GB77578@neutralgood.org> <20150212180231.737ea2ba@B85M-HD3-0.alogt.com> <20150212232145.GG1953@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, On Thu, 12 Feb 2015 15:21:45 -0800 John-Mark Gurney <jmg@funkthat.com> wrote: > Erich Dollansky wrote this message on Thu, Feb 12, 2015 at 18:02 > +0800: > > On Thu, 12 Feb 2015 00:20:58 -0500 > > kpneal@pobox.com wrote: > > > 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? > > Sadly, it looks like we may have to introduce a new i386 > "platform"/ABI in order to deal w/ the fact that time_t is only > 32bits to address the 2038 problem.. we are in a real hurry then ... > > > > 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. > > It wasn't till C99 that int32_t and friends were standardized... So, I know. As I was used to develop hardware plus the software to run it, I was forced from the beginning to make sure that a data type matches 100% the hardware. > lots of programming was done long before sized types were standard... > Before then people were rolling their own, or simply assuming the > sizes... Though as standards go, Microsoft still refeses to add these > standard types, causing all sorts of problems.. > It seems that I am lucky there. > > 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. > > I don't know of any int size other than 32bit for all supported > FreeBSD platforms.. All platforms are either ILP32 or LP64 as far as > I know.. > I do not know. I am just allergic against all potential problems. Why allow a problem to come in quietly if we can easily avoid it. Irony is that one of my own programs has had a solution I did not like. When I saw top running, I realised that top must have a code similar to my code. So, I started to dig and found this by chance. I did not think at all that the discussion will get out of scale like this. Erich
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150213154030.00a03e81>