From owner-freebsd-stable@FreeBSD.ORG Thu Feb 12 10:02:46 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9CD24A34 for ; Thu, 12 Feb 2015 10:02: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 6A130950 for ; Thu, 12 Feb 2015 10:02: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=UH41TKtz/nUF7Lsba2Htee9RIBqmIVN2gFWdzOjKZig=; b=q+VFU89wDkahT1r8fZkPhbqyMRn5CGrZuUmRAtPNc23M/4BFa+SZkxnnKZj5cAr3Qjy/58P5a00ecSvhfnSz0OG6mXCQosnK1Y6xSBOX8A4nquLXIGu9UQqNdI3KZZEVCrl/AfzjE7RwnDgmGBiYuVe50zVf/nM0RXbl4lzKYH8=; Received: from [114.124.26.148] (port=51600 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 1YLqbb-002dTB-GT; Thu, 12 Feb 2015 03:02:44 -0700 Date: Thu, 12 Feb 2015 18:02:31 +0800 From: Erich Dollansky To: kpneal@pobox.com Subject: Re: top, fixed buffer length in utils.c Message-ID: <20150212180231.737ea2ba@B85M-HD3-0.alogt.com> In-Reply-To: <20150212052058.GB77578@neutralgood.org> 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> 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: John-Mark Gurney , freebsd-stable@freebsd.org 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: Thu, 12 Feb 2015 10:02:46 -0000 Hi, On Thu, 12 Feb 2015 00:20:58 -0500 kpneal@pobox.com wrote: > On Wed, Feb 11, 2015 at 10:33:21PM -0600, Bob Willcox wrote: > > On Thu, Feb 12, 2015 at 09:13:23AM +0800, Erich Dollansky wrote: > > > On Tue, 10 Feb 2015 17:14:41 -0600 > > > Bob Willcox wrote: > > > > On Mon, Feb 02, 2015 at 04:33:07PM -0800, John-Mark Gurney > > > > wrote: > > > > > Erich Dollansky wrote this message on Sun, Feb 01, 2015 at > > > > > 17:51 +0800: > > > If you want, just read the old discussion regarding time_t. > > > > Oh, I've been around since ints were 8 bits (on really old stuff) > > and appreciate the issues. However my point wasn't that assuming > > the size is good, but that when ints change we will have lots more > > serious breakage is all. > > 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? > 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. > And I submit that the days of int changing with the compiler are long > past. It causes too much havoc. The Amiga had two different sizes of > int based on the two major vendor compilers, and when Commodore > ported the BSD sockets API they had to change all ints to longs. > > Just look at how many POSIX APIs use ints. If int were to change with > the compiler, and so different compilers on the same target were > different, then _every_ _single_ int used by POSIX would need to be > changed. 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. > > Who thinks that's likely? > > Why on Earth would any vendor do something so costly? And why would > the rest of the standards bodies (including POSIX) go along with it? > What says POSIX about the size of int? POSIX just follows the size the compiler uses on a platform. > No, when the day int changes size comes it will be due to computers > being changed in some way that is so fundamental that we may not even > recognize it as a computer. Perhaps it will be organic, or perhaps it > will be a quantum computer. > > Can we please put this issue to rest already? Hopefully. Erich