BigDisk project: du(1) 64bit clean.

[Doug White]

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 at gumbysoft.com          |  www.FreeBSD.org