Mark Dickinson <[email protected]> added the comment:
After a bit more thought (and after soliciting a couple of opinions on
#python-dev), I'm convinced that endianness changes within a substruct should
be local to that substruct:
- it makes the meaning of '>2T{H<H}' both unsurprising and easy to understand:
i.e., it would be interpreted exactly as '>T{H<H}T{H<H}', and both substructs
would behave like '>H<H'.
- I suspect it's the behaviour that people expect
- it may make dynamic creation of struct format strings easier/less bug-prone.
But now I've got a new open issue: how much padding should be
inserted/expected (for pack/unpack respectively) between the 'B' and the
'T{...}' in a struct format string of the form 'BT{...}'?
For this, I don't think we can hope to exactly comply with the platform ABI in
all cases. But I think there's a simple rule that would work 99% of the time,
and that does match the ABI on common platforms (though I'll check this),
namely that the alignment requirement of the 'T{...}' struct should be the
least common multiple of the alignment requirements of any of its elements.
(Which will usually translate to the largest of the alignment requirements,
since those alignments are usually all going to be powers of 2.)
And *this* is where things get tricky if the alignment/byteorder/size specifier
is changed midstream, since then it doesn't seem clear what alignments would
contribute to the lcm above. I'm tempted to suggest that for native mode,
changing the specifier be disallowed entirely.
Travis, any comments on any of this?
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue3132>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
