[SciPy-User] SciPy-User Digest, Vol 80, Issue 22

[Scott Ransom]

On Tuesday 13 April 2010 12:22:12 pm Tom Kuiper wrote:
> Scott Ransom wrote:
> > On Tuesday 13 April 2010 11:39:21 am Tom Kuiper wrote:
> >> Thanks for the tip Robert.
> >>
> >> On my 32-bit laptop:
> >> In [11]: calcsize('HHHH L HHH L d L H')
> >> Out[11]: 38
> >>
> >> On a 64-bit machine:
> >> In [3]: calcsize('HHHH L HHH L d L H')
> >> Out[3]: 50
> >
> > That's probably not because of the padding.  It is likely due to the
> > fact that longs are 4 bytes on 32-bit machines and 8 bytes on 64-bit
> > machines.
> >
> > Scott
> 
> Hi Scott,
> 
> I thought of that.  4xL would be the same as Q.  But I'm confused that
> the 'pads' are not always adjacent to the longs.
> 
> This works on my 32-bit machine.  (The file was written by the 64-bit
> machine.)
> 
> header = unpack_from('=4H L H 4x 2H L 4x d L 4x H',buf)
> 
> If I changed all the longs to long longs on my 32-bit machine, I don't
> think it would solve the problem.
> 
> Regards
> 
> Tom

I think most padding is actually done next to the shorts.  That is because 
the compiler tries to make all of the data align on 4- or more typically 
8-byte boundaries.  Therefore, if you rearrange and put all the longs 
first, they will naturally be aligned (esp on 64-bit platforms) and the 
first short afterwards will also be aligned automatically.  If you have an 
odd number of shorts, though, there will likely be padding at the end of 
the shorts if you have another datatype afterwards.

Scott



-- 
Scott M. Ransom            Address:  NRAO
Phone:  (434) 296-0320               520 Edgemont Rd.
email:  sransom at nrao.edu             Charlottesville, VA 22903 USA
GPG Fingerprint: 06A9 9553 78BE 16DB 407B  FFCA 9BFA B6FF FFD3 2989