Message182430
| Author |
pitrou |
| Recipients |
Ramchandra Apte, alanh, christian.heimes, ezio.melotti, jcea, pitrou, serhiy.storchaka, skrah, trent |
| Date |
2013年02月19日.21:02:21 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1361307538.19503.6.camel@localhost.localdomain> |
| In-reply-to |
<1361307295.81.0.25108877408.issue17237@psf.upfronthosting.co.za> |
| Content |
> It must be about pointer alignment, because that's the whole point of
> the ASSERT.
Indeed, it's about pointer alignment, but it's not about the CPU. It's
about the compiler (or the platform's C ABI).
Apparently the compiler doesn't align struct fields to natural
boundaries like most other compilers do, which means the size of the
PyASCIIObject struct (in unicodeobject.h) ends up not being a multiple
of 4, which in turn means the "dest" pointer (allocated from the end of
that structure) is not 4 byte-aligned either.
However, you can probably safely remove the assert(), since it is there
to warn about misalignment on platforms which *are* alignment-sensitive.
There is another assert() of the same kind in unicodeobject.c, which you
can remove too.
It would be nice if the C source could be improved here, but it's not
obvious which rule to enforce exactly. We want to be lenient if the
misalignment is a product of the compiler's alignment rules, but not if
it's a mistake on our part.
Which compiler is it? |
|