From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 07:40:46 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CEC1B3AB for ; Fri, 13 Feb 2015 07:40:46 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A22F76DC for ; Fri, 13 Feb 2015 07:40:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=5iqzwtZKrsv/ThZE5Fg1I3uAgPwR3a/UHPRRLUlIUwo=; b=W75r1qb0ZTg1J278rr7Ap1WBVKb557dGbE2J8kZezzzkhNThDwxe6DtU+69482+b+Kynk0HPNuRrFkmQtcy7oB8Xj88zEFdjIq2Blcn2ra9+2lVMmrAhTm+qtrlLx8eyHTshgXm7v6kBYSG0B3XLiYClCQ0JHaHIbHQ1XtLmVek=; Received: from [114.124.26.58] (port=55206 helo=B85M-HD3-0.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1YMAre-000sY2-2I; Fri, 13 Feb 2015 00:40:39 -0700 Date: Fri, 13 Feb 2015 15:40:30 +0800 From: Erich Dollansky To: John-Mark Gurney 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> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-stable@freebsd.org, kpneal@pobox.com X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 07:40:47 -0000 Hi, On Thu, 12 Feb 2015 15:21:45 -0800 John-Mark Gurney 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