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