misaligned access

[Davy Durham <david dot durham at wcom dot com>]

Hi all,
    A while back (2 or 3 months) I asked a question about misaligned
access.... I didn't get much help, but while reading through the gcc
extensions chapter I found a solution to my problem..

Situation:
    buffer'o'data ->
[.....................................................................................................]

    Where
    structures (with no padding or alignment) exist in that buffer
consecutively... The structures vary in structure and size according to
the first byte of the structure (TLV situation).... And they exist as
many as can be until one would overrun the buffer, hence there may be
wasted space at the end...

Please don't scorn me.. I know it's a crappy design..... but these are
files coming from Nortel switches and we just have to deal with it...

Anyway, on the sparc platform you'll get a bus error and coredump if you
attempt to read a 32 int from an address not aligned on a 4 byte
boundary so this is the reason we had a problem....

    Sun's compiler had a -misalign flag that would make all fetches be
done 1 byte at a time, resulting in int a=5.. being a 3 right shifts and
4 byte stores.. ugh..... So the misalign flag would slow down the whole
program unless you put just the problematic code into a separate module,
but we want to access this structure in many places all over the code...

Well, the extension I found was a variable attribute , "packed" or
likewise I suppose, "aligned(1)"...

so let the struct be:

#define MA __attribute__ ((packed))
struct foo
{
    char a MA;
    int b MA;
    short c MA;
}

And I can point a foo * anywhere to any address not aligned i.e.
anywhere in the buffer'o'data... And I don't get a bus error on
sparc.... I tested it..

Once again, gcc comes through (just a little late)...  It's much better
than Sun's solution in that it doesn't slow everything else down to have
the struct be misaligned... However, I must admit, I haven't read the
Sun's compiler's documentation to know whether it has a similar
extension... but who cares...


Happy,
    --Davy