BigDisk project: du(1) 64bit clean.

[Scott Long]

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