Date: Wed, 5 Jan 2005 16:17:00 +1100 From: Peter Jeremy <PeterJeremy@optushome.com.au> To: Pawel Jakub Dawidek <pjd@freebsd.org> Cc: scottl@freebsd.org Subject: Re: BigDisk project: du(1) 64bit clean. Message-ID: <20050105051700.GJ34222@cirb503493.alcatel.com.au> 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, 2005-Jan-04 23:40:43 +0100, Pawel Jakub Dawidek wrote: >I want you to look at two patches which makes du(1) 64bit clean. You might also like to look at the thread beginning http://lists.freebsd.org/pipermail/freebsd-hackers/2004-December/009427.html > http://people.freebsd.org/~pjd/patches/fts.h.patch > >It adds 64bit fts_bignum field, but because it is hiden under union, >it doesn't break ABI. It also doesn't break API, thanks to #defines. Very nice. Much cleaner than my suggestions. All of our supported architectures are either I32LP64 or ILP32 (ignoring bde's IP32L64 i386 variant) therefore the union won't affect alignment or alter padding. Since NULL is physically represented by all zero bits on all our architectures, fts_bignum is even correctly initialised to zero - though this bit isn't standards compliant. >We should decide if we want fts.h.patch also in HEAD or only in RELENG_5, >because we can make it much cleaner in HEAD, but we will break ABI >(API should be quite ok) - we need to change size of fts_number field. I gather you're suggesting that fts_number be changed to int64_t in HEAD. I'm less convinced about this - though if this change is made, it should be done sooner rather than later. The only downside is that ls(1) will bloat further on 32-bit architectures (I recall seeing at least one complaint about running ls on a ludicrously big directory). fts(3) is a BSD4.4 invention. The 4.x man page suggests future standardisation by POSIX but this statement disappeared in v1.14 without any comment in the commit logs. Rather than changing fts_number to int64, I suggest leaving the patch and documenting that fts_bignum overlays both fts_number and fts_pointer. The need for fts_bignum will probably disappear in time. -- Peter Jeremy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050105051700.GJ34222>