> 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.