Date: Tue, 4 Jan 2005 18:58:33 -0800 (PST) From: Doug White <dwhite@gumbysoft.com> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: scottl@freebsd.org Subject: Re: BigDisk project: du(1) 64bit clean. Message-ID: <20050104183627.O20855@carver.gumbysoft.com> In-Reply-To: <20050104224043.GM784@darkness.comp.waw.pl> References: <20050104224043.GM784@darkness.comp.waw.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050104183627.O20855>