Mon 27 Feb 2006 06:27:08 PM UTC, comment #1:
Wow. I always knew that `gen-alignment' would eventually
come back and bite me somehow -- I just never knew exactly
how. Now I do.
If I'm following the reports correctly, the real bug
is in the invariant check. The invariant check makes
a false assumption that the machine's strictest alignment
requirements are determined by the size of the largest
scalar type.
The macro MACHINE_ALIGNMENT is poorly named. It should
really be something like:
CONSERVATIVE_ESTIMATE_OF_MACHINE_ALIGNMENT
The primary use of MACHINE_ALIGNMENT is to safely wrap
`malloc' in an allocator that adds a header to allocated
memory. `ar.c' is an example of such an allocator.
The user asks for N bytes. We want a K byte header.
So we allocate:
N + ALIGNMENT * ((K + ALIGNMENT - 1) / ALIGNMENT)
bytes, put the header at byte 0, and start the user data
at byte:
ALIGNMENT * ((K + ALIGNMENT - 1) / ALIGNMENT)
The invariant that we are truly trying to maintain is that,
so long as `malloc' returns memory suitably aligned for anything,
so does our wrapper (such as the `ar' functions).
The actual invariant test in the code tests for a stricter
condition that happens not to be true in this case. It's
the invariant, not `gen-alignment', that is bogus.
A fix that showed up on the Red Hat bugzilla involved computing
MACHINE_ALIGNMENT differently. That "fix" introduces a bug
(that may or may not actually effect existing architectures)
and should not be made. It's the call to `invariant' that
contains the bug.
-t
|