Thanks Steve. So what is the best way of laying down a structure definition
to over come cross platform issues?
I read about introducing some explicit padding in the structure to take care
for cross platform issues but for that I suppose one should have information
about byte alignment & structure padding on all targeted platforms. Is that
true or there is some generic way of doing that? (Apart from using compiler
option to remove any padding )

Regards,
Amit Dang
----- Original Message ----- 
From: "Steve Graegert" <[EMAIL PROTECTED]>
To: "Amit Dang" <[EMAIL PROTECTED]>
Cc: <[email protected]>
Sent: Tuesday, August 02, 2005 12:12 PM
Subject: Re: Any pointer to Byte Alignment & Structure Padding?


> On 8/2/05, Amit Dang <[EMAIL PROTECTED]> wrote:
> > Do you mean that max byte alignment on a 32-bit machine is 4 bytes? If
we
> > move to 64-bit machine will the size of this structure be 24 bytes?
>
> 32-bit machines' maximum alignment is 4 bytes and 64-bit machines
> align up to 8 bytes.  This does not mean that all integral types are
> padded to 8-byte boundaries.  Yes, the size of the structure will
> change to 24 bytes, because the most efficient offset for the long
> member is at byte 16 and not byte 12.  It is very likely that a
> padding of 4 bytes will be inserted after the 3rd structure member.
> As a result the size of the structure will increase to 24 bytes.
>
> On IA64 long and long long, both signed and unsigned, are 8-byte
> aligned, while int is 4-byte, short 2-byte and char 1-byte aligned.
> Nevertheless, padding is needed for short and char to align to 4-byte
> boundaries.  Therefore the size of the structure would not change,
> since the member of type long is 4-byte aligned already, but
> unfortunately its layout in memory is very inefficient.  The
> increasing size of the structure in this particular case is not a
> result of the alignment itself but of the compiler's efforts to
> optimize memory layout.
>
> Normally a structure is also padded at the end in order to make the
> size a multiple of the alignment if needed.  Rules for alignment are
> compiler and platform specific.
>
> Regards
>
> \Steve
>
>
> > ----- Original Message -----
> > From: "wwp" <[EMAIL PROTECTED]>
> > To: <[email protected]>
> > Sent: Monday, August 01, 2005 7:41 PM
> > Subject: Re: Any pointer to Byte Alignment & Structure Padding?
> >
> >
> > > Hello Amit,
> > >
> > >
> > > On Mon, 1 Aug 2005 17:57:48 +0530 "Amit Dang"
> > > <[EMAIL PROTECTED]> wrote:
> > >
> > > > Hi Vadiraj,
> > > >     Thanks for the explaination but when i try following structure
> > > > struct temp
> > > >  {
> > > >         char c;   /* 1 byte lenght */
> > > >         int i;      /* 4 byte length */
> > > >         char c1; /* 1 byte length */
> > > >         long long d /* 8 bytes  lenght */
> > > >  };
> > > > on a linux machine x86 32-bit with gcc 2.96. It gives its size = 20
> > bytes
> > > > not 24 bytes (as explained by you)
> > >
> > > See below (this applies to both members sorting examples from
Vadiraj):
> > >
> > > struct           padded  offset
> > > member     size  size    range
> > > -------------------------------
> > > c          1     4       0-3
> > > i          4     4       4-7
> > > c1         1     4       8-11
> > > d          8     8       12-19
> > >
> > > So, 20 bytes. Isn't it right?
> > >
> > >
> > > Regards,
> > >
> > > > ----- Original Message -----
> > > > From: "Vadiraj" <[EMAIL PROTECTED]>
> > > > To: "Amit Dang" <[EMAIL PROTECTED]>
> > > > Sent: Monday, August 01, 2005 5:44 PM
> > > > Subject: Re: Any pointer to Byte Alignment & Structure Padding?
> > > >
> > > >
> > > > > On 8/1/05, Amit Dang <[EMAIL PROTECTED]>
wrote:
> > > > > > Hi,
> > > > > >    Can any body provide some light on Byte Alignment & Structure
> > Padding
> > > > > > for gcc linux x86 32-bit?
> > > > >
> > > > >  The system expects the address of a variable to be multiple of
> > > > > its size. Meaning for 32 bit x86 int being 4 bytes. The address
> > > > > location of a int variable is expected to be at multiple of 4.
> > > > > ex 0 4 8 12 16. if  its double then its expected it to be multiple
of
> > 8.
> > > > > 0 8 16 ...
> > > > >
> > > > >  In case of structure allignment... this is achieved by padding.
> > > > > if this is the structure
> > > > > struct temp
> > > > > {
> > > > >        char c;   /* 1 byte lenght */
> > > > >        int i;      /* 4 byte length */
> > > > >        char c1; /* 1 byte length */
> > > > >        long long d /* 8 bytes  lenght */
> > > > > };
> > > > >
> > > > >  c starts at offset x( x is assured 4 byte alligned by gcc), i
should
> > > > > start at x+4 as it has to be multiple of 4 3 bytes of padding will
be
> > > > > done by gcc.
> > > > > c1 starts at x+9, no padding is required char is 1 byte.
> > > > > d starts at x+16,7 bytes of padding to get multiple of 8.
> > > > >
> > > > > It would differ if you re arrange the struct like this.
> > > > > struct temp
> > > > > {
> > > > >        char c;   /* 1 byte lenght */
> > > > >        int i;      /* 4 byte length */
> > > > >        long long d /* 8 bytes  lenght */
> > > > >        char c1;
> > > > > };
> > > > >
> > > > > for same base offset...i will be from x+4 d would start from x+8,
> > > > > there would be no padding for d  and c1 at x+16.
> > > > >
> > > > > I hope it helps.
> > > > > --
> > > > > cheers,
> > > > > Vadi
> > > >
> > > > -
> > > > To unsubscribe from this list: send the line "unsubscribe
> > > > linux-c-programming" in the body of a message to
> > [EMAIL PROTECTED]
> > > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > > >
> > >
> > >
> > > --
> > > wwp
> > >
> > > -
> > > To unsubscribe from this list: send the line "unsubscribe
> > linux-c-programming" in
> > > the body of a message to [EMAIL PROTECTED]
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe
linux-c-programming" in
> > the body of a message to [EMAIL PROTECTED]
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
>
>
> -- 
>                                  ______________________________________
> Steve Graegert                  //
> Software Consultancy           //    Whether you know it or not, if you
> Mobile: +49 (176)  21248869   // are a hacker, you are a revolutionary.
> Office: +49 (9131) 7126409   //  Don't worry, you're on the right side.
> ____________________________//         -- Dr Crash / Phrack 6 / phile 3

-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" 
in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to