> > Some things just require confirmation...can someone else (Thomas?) running
> > Linux comment on this before I apply it? I just find it kinda unexpected
> > to see something that doesn't work for SCO doesn't work for Linux too :)
>
> On BSDI, malloc man pages says:
>
> The allocated space is suitably aligned (after possible pointer coercion)
> for storage of any type of object.
>
> I don't believe this is a standard, and I think Linux may not follow it.
> I think I heard somewhere they don't. We certainly need to have this
> checked before use in a patch.
The alignment of a pointer returned from malloc() is platform specific. The
BSDI man page above gets the sense of it right, and as far as I am aware
all mallocs conform to this restriction. In particular x86 Linux malloc
behaves exactly that way.
Of course on x86 there is no special requirement any type to be aligned at all.
Double do not need to be 8 byte aligned. Ints do not need to be on an even
address etc. So malloc can return a pointer to any address it wants on an x86
and still conform to the restriction.
On a Sparc or an Alpha, objects must to be aligned to the sizeof the type.
So shorts are 2 byte aligned, ints 4 byte, and doubles 8 byte. Since malloc
has no idea what you are allocating it has to return an 8 byte aligned pointer.
But all this is a bit of a red herring. The original bug if I recall was
caused by the caller assuming that the return from palloc was 8 byte aligned.
Since the caller "knew" that the pointer was 8 byte aligned it then went on
to do some "fancy" pointer arithmetic to arrive at an offset. This is what
is broken, not the Linux malloc().
That said, I have a plan in mind to get a nice performance boost for palloc().
As a side effect, I will guarantee 8 byte alignment of pointers returned
from palloc().
-dg
David Gould dg@illustra.com 510.628.3783 or 510.305.9468
Informix Software (No, really) 300 Lakeside Drive Oakland, CA 94612
- I realize now that irony has no place in business communications.
