From owner-freebsd-arch@FreeBSD.ORG  Wed Jan  5 03:12:09 2005
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 6FC3416A4CE; Wed,  5 Jan 2005 03:12:09 +0000 (GMT)
Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 0FD4B43D3F; Wed,  5 Jan 2005 03:12:09 +0000 (GMT)
	(envelope-from scottl@freebsd.org)
Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11])
	(authenticated bits=0)
	by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id j053F0rF015546;
	Tue, 4 Jan 2005 20:15:01 -0700 (MST)
	(envelope-from scottl@freebsd.org)
Message-ID: <41DB5AAB.9080705@freebsd.org>
Date: Tue, 04 Jan 2005 20:10:35 -0700
From: Scott Long <scottl@freebsd.org>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040929
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Doug White <dwhite@gumbysoft.com>
References: <20050104224043.GM784@darkness.comp.waw.pl>
	<20050104183627.O20855@carver.gumbysoft.com>
In-Reply-To: <20050104183627.O20855@carver.gumbysoft.com>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org
cc: arch@freebsd.org
cc: Pawel Jakub Dawidek <pjd@freebsd.org>
Subject: Re: BigDisk project: du(1) 64bit clean.
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Discussion related to FreeBSD architecture
	<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Jan 2005 03:12:09 -0000

Doug White wrote:
> On Tue, 4 Jan 2005, Pawel Jakub Dawidek wrote:
> 
> 
>>I want you to look at two patches which makes du(1) 64bit clean.
>>This work is part of the BigDisk project:
>>
>>	http://www.freebsd.org/projects/bigdisk/
>>
>>The main problem here is that du(1) uses fts(3) and fts_number field from
>>one of its structures to store size.
>>This field is defined as 'long' so it doesn't give us what we want
>>(on 32bit archs).
> 
> 
> No offense intended, but can we avoid introducing LP64 bugs, please?
> Particularly when the goal is "ABI compatibility."*
> 
> dwlab3,ttyp1,~,24>uname -m
> i386
> dwlab3,ttyp1,~,25>./test
> sizeof(long) [4] + sizeof(void *) [4] == 8 == sizeof(int64_t) [8]
> 
> ok .. but:
> 
> dwlab4,ttyp1,~,20>uname -m
> amd64
> dwlab4,ttyp1,~,21>./test
> sizeof(long) [8] + sizeof(void *) [8] == 16 != sizeof(int64_t) [8]
> 
> oops! The struct just grew by 8 bytes!
> 
> (*) On the same platform, obviously.
> 

I'm not sure how you are getting this.  The structure goes from

	long fts_number;	        /* local numeric value */
	void *fts_pointer;	        /* local address value */

to

	union {
		struct {
			long __fts_number;	/* local numeric value */
			void *__fts_pointer;	/* local address value */
		} __struct_ftsent;
		int64_t __fts_bignum;
	} __union_ftsent;


Regardless of how big a pointer or a long is on your platform, the two
fields are going to combine to consume at least 64 bits.  All that the
change does is overlay those >= 64bits with a int64_t.

Scott