Re: BigDisk project: du(1) 64bit clean.

From: Doug White (dwhite_at_gumbysoft.com)
Date: 01/05/05

  • Next message: Peter Jeremy: "Re: BigDisk project: du(1) 64bit clean." 
    Date: Tue, 4 Jan 2005 19:46:06 -0800 (PST)
To: Scott Long <scottl@freebsd.org>

    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@gumbysoft.com          |  www.FreeBSD.org
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
  • Next message: Peter Jeremy: "Re: BigDisk project: du(1) 64bit clean."

    Relevant Pages

    • <::taps::> Lawrence Scott, Reilly Raiders Founding Charter Member (obit)
      ... loving father of Larry Scott. ... Mr. Scott was a Founding Charter member of Reilly Raiders Drum Corps, in 1946, a ... member of National and Eastern States Judges, ... friends and members of Reilly Raiders are invited to Lawrence's Life ...
      (rec.arts.marching.drumcorps)
    • Re: Static Class Constants (VB 2005)
      ... Regardless of Option Explicit and Option Strict settings on a brand new form ... with a single button, I get the error "Access of shared member, constant ... > Dim ClassConst As String = XMyClass.ConstantString ...
      (microsoft.public.dotnet.languages.vb)
    • Re: D50 LCD Monitor Preview??
      ... this forum shares many attributes of numerous others on the ... 'net' - regardless of their subject matter. ... If you've already answered it before, don't bother - I'm ... I can only hope that the member takes not ...
      (rec.photo.digital.slr-systems)
    • Re: Scott Savage under fire at University
      ... recommendation he made. ... As a member of the campus' First Year Reading Experience ... Scott suggested some books which provide a contrasting view ...
      (soc.religion.quaker)
    • Re: Defining "<" for the rationals
      ... I've been able to show that the definitions of multiplication and addition give the same answer, regardless of which member of an equivalance set is chosen. ... Is there a cleaner way to define the less than relation on rationals? ...
      (sci.math)