Date: Tue, 04 Jan 2005 20:10:35 -0700 From: Scott Long <scottl@freebsd.org> To: Doug White <dwhite@gumbysoft.com> Cc: Pawel Jakub Dawidek <pjd@freebsd.org> Subject: Re: BigDisk project: du(1) 64bit clean. Message-ID: <41DB5AAB.9080705@freebsd.org> In-Reply-To: <20050104183627.O20855@carver.gumbysoft.com> References: <20050104224043.GM784@darkness.comp.waw.pl> <20050104183627.O20855@carver.gumbysoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41DB5AAB.9080705>