Meador Inge <mead...@gmail.com> added the comment:

> I'm half-convinced that struct.pack *should* ideally add trailing 
> padding in the same situation that C does, for consistency with C.  
> Then calcsize would match C's sizeof.

Maybe...  AFAIK, the C language does not mandate structure padding.
Section 6.7.2.1 of the C99 standard says that "unnamed padding" may be inserted 
anywhere inside of a structure object *except* at the beginning.  In other 
words, padding between members and trailing  padding is very implementation 
specific.  

When and why things are padded usually depends on the compiler, OS, and 
computer architecture.  For example, padding between members is usually
just an optimization for architectures like x86, but on architectures like ARM 
and MIPS you may end up with alignment faults.  Moreover, I 
think trailing padding is typically added to maintain alignment for 
arrays of structures, which again may be an optimization or correctness issue 
depending on the architecture.

So, I don't think we can match what C does since C leaves it open.
Perhaps we could match the C implementation that compiles the 'struct'
module, though?  Maybe there is a way we can compute the trailing padding in a 
fashion similar to how alignment is computed for various
types in the '*_ALIGN' macros in '_struct.c'?

Another thing that came to mind when thinking about structure layout issues was 
whether it might be useful to provide "packed" structures, e.g. no padding.  If 
the goal is to provide a way to read\write C-compatible structs, then currently 
there is no easy way to handle structures that have been serialized after being 
compiled with something like GCC's '-fpack-struct' option.

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue7355>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to