current cvs segfault on Debian hppa
Eric Seppanen
eds at reric.net
Thu Oct 3 21:43:18 CEST 2002
On Thu, Oct 03, 2002 at 09:32:21PM +0200, Matthias Andree wrote:
> On Thu, 03 Oct 2002, Eric Seppanen wrote:
>
> > Someone back me up on this: if hmalloc() is returning odd addresses and
> > we're laying down structures at that address, we're broken on many
> > architectures, right?
>
> It will break or slow down m68k, break MIPS, and apparently it breaks
> HP-PA. However, how do we figure if the machine in question needs 16, 32
> or 64-bit aligned addresses? How will this scale on really big boxes?
> Might there be machines that need 128 bit alignment?
There are two possible approaches:
1. Write code in a way that the compiler takes care of this. That's the
idea in getting rid of the hmalloc() wrapper.
2. Figure out the alignment and handle it manually. I believe that the
restrictions for reasonably portable code are:
- alignment of basic types is usually the same as the type size, i.e.
32-bit integers need 4-byte alignment and doubles need 8-byte alignment.
... sizeof(double) is usually the worst case.
- structures must be aligned only as much as their most restrictive
member variable, i.e. a struct with only 32-bit integers only needs 32-bit
alignment, while a struct with a mix of integers and doubles needs 8-byte
alignment (assuming doubles are 8 bytes).
So I think that we'd be OK with alignment to sizeof(double), but
eliminating the problem code and letting the compiler (and the malloc
library) handle it is easier and probably more robust in the long term.
malloc() is guaranteed to be properly aligned for _any_ data type.
For summay digest subscription: bogofilter-digest-subscribe at aotto.com
More information about the Bogofilter
mailing list