Thanks for the helpful feedback. I guessed it was the alignment issue,
but could not find the exact format for changing the default. It is not
mystery any more!
Bengt Richter wrote:
> On 7 Nov 2005 15:27:06 -0800, "Chandu" <[EMAIL PROTECTED]> wrote:
>
> >In using the following struct format I get the size as 593. The same C
> >struct is 590 if packed on byte boundary and 596 when using pragma
> >pack(4). I am using pack(4) and added 3 spares at the end to get by.
> > hdrFormat = '16s 32s 32s B 8s H 8s H 4s H H 20s 64s 64s 64s 32s 32s
> >64s L L B B B B B 64s 64s'
> >
> >Any ideas on what I am doing wrong?
> >
> Looks to me like you are getting default native byte order and _alignment_
> and some pad bytes are getting added in. For native order with no padding,
> try prefixing the format string with '='
>
>
> >>> hdrFormat
> '16s 32s 32s B 8s H 8s H 4s H H 20s 64s 64s 64s 32s 32s 64s L L B B B B B
> 64s 64s'
>
> If you add up the individual sizes, padding doesn't happen, apparently:
>
> >>> map(struct.calcsize, hdrFormat.split())
> [16, 32, 32, 1, 8, 2, 8, 2, 4, 2, 2, 20, 64, 64, 64, 32, 32, 64, 4, 4, 1, 1,
> 1, 1, 1, 64, 64]
> >>> sum(map(struct.calcsize, hdrFormat.split()))
> 590
>
> But default:
> >>> struct.calcsize(hdrFormat)
> 593
> Apparently is native, with native alignment & I get the same as you:
> >>> struct.calcsize('@'+hdrFormat)
> 593
> Whereas native order standard (no pad) alignment is:
> >>> struct.calcsize('='+hdrFormat)
> 590
> Little endian, standard alignment:
> >>> struct.calcsize('<'+hdrFormat)
> 590
> Big endian, standard alignment
> >>> struct.calcsize('>'+hdrFormat)
> 590
> Network (big endian), standard alignment:
> >>> struct.calcsize('!'+hdrFormat)
> 590
>
> I guess if you want alignment for anything non-native, you have to specify
> pad bytes
> where you need them (with x format character).
>
> Regards,
> Bengt Richter
--
http://mail.python.org/mailman/listinfo/python-list
