>> This may not be recognized so far, because there is no builtin >> GC-enabled type that embeds a double. >> But if you create such a type, then the double will be correctly >> aligned in your object's structure, but then, when the object >> gets allocated, it is misaligned, because the header size is not a >> multiple of 8. > > I'm not sure a double aligned on a 4-byte boundary is "misaligned" on a x86 > CPU.
That's not really the point. The question is whether the double is misaligned wrt. the compiler's ABI. The compiler (or the operating system) specifies the alignment for all primitive types, and guarantees that everything is properly aligned. > Alignment is primarily important to avoid access violations on CPUs and > datatypes which don't support arbitrary alignment, although it can also be > useful for performance reasons. Alignment may also have propagated into other aspects. For example, if you have double foo; intptr_t bar = (intptr_t)&foo; then it may be guaranteed (by the ABI) that bar&7 == 0. So we really need to keep all promises wrt. alignment intact. > In any case, you seem to be right on this particular point: the PyGC_Head > union > should probably contain a "double" alternative in addition to the "long > double" > (and perhaps even a "long long" one). I agree. Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
