From owner-freebsd-arch@FreeBSD.ORG  Wed Jan  5 03:46:06 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 EEE1D16A4CE; Wed,  5 Jan 2005 03:46:06 +0000 (GMT)
Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id D5A9D43D1F; Wed,  5 Jan 2005 03:46:06 +0000 (GMT)
	(envelope-from dwhite@gumbysoft.com)
Received: by carver.gumbysoft.com (Postfix, from userid 1000)
	id C62E872DD4; Tue,  4 Jan 2005 19:46:06 -0800 (PST)
Received: from localhost (localhost [127.0.0.1])
	by carver.gumbysoft.com (Postfix) with ESMTP id C12C272DCB;
	Tue,  4 Jan 2005 19:46:06 -0800 (PST)
Date: Tue, 4 Jan 2005 19:46:06 -0800 (PST)
From: Doug White <dwhite@gumbysoft.com>
To: Scott Long <scottl@freebsd.org>
In-Reply-To: <41DB5AAB.9080705@freebsd.org>
Message-ID: <20050104194302.O21516@carver.gumbysoft.com>
References: <20050104224043.GM784@darkness.comp.waw.pl>
 <20050104183627.O20855@carver.gumbysoft.com> <41DB5AAB.9080705@freebsd.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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:46:07 -0000

On Tue, 4 Jan 2005, Scott Long wrote:

> > 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.

Oops, you're right.  Since the new member is <= in size to the previous
members, strictly speaking it shouldn't change size.

Now there is a question if gcc will do something odd to that embedded
struct for alignment purposes. I haven't checked the original code for
__packed, however...

I'm also not clear on if endianness plays a part, but I need to read the
code.

-- 
Doug White                    |  FreeBSD: The Power to Serve
dwhite@gumbysoft.com          |  www.FreeBSD.org