>> 	64-bit assignment statements tend to cause bus errors if misaligned.
>>   Other OS's simply report an alignment error, generate a couple of extra
>>   instructions, and get on with life. I don't know exactly what is causing
>>   this behavior, but it should probably be changed to make porting easier.
>>   If unintentional, then it's a bug and should be fixed :)

>It might be nice to provide an option so that the
>user can _enable_ fixups, but it shouldn't be mandatory.

>I've yet to see a case where an unaligned access in any of the NetBSD
>source tree was anything other than a programming bug.  From the
>"good" developer's standoint, printing a warning tells you that
>there's a bug, but gives you no opportunity to debug it.  From the
>"bad" developer's standpoint, the only things that are actually bugs
>are those which cause incorrect operation or which crash the program,
>so unaligned accesses (which generally do indicate broken code, and
>which do significantly slow down program operation if they happen
>often enough) "aren't really bugs."

Well, I first encountered the problem not as a developer but as an end-user
of third-party software. The software worked everywhere else in the world
but just died with a bus error on this machine. Quite frustrating, you
understand. The average user never wants to see their favorite software
croak "Bus error" and die.

After gaining experience with unix and C (no longer the average user), I was
finally able to go back and figure out what had made the software behave like
that. The author had used a buffer tagging scheme on a pool of dynamically
allocated memory. For each chunk allocated, he slapped on a header and a
footer, and returned a pointer to memory starting at the end of the header.
Due to a ridiculous combination of type sizes, NetBSD/sparc appears to be the
only platform on which the header size and the kinds of data stored in these
buffers interact to produce misalignment problems.

His header struct consists of two ints and three pointers, so I suggested he
add something like 
  char align[(8-(2*sizeof(int)+3*sizeof(char*))%8)%8];
to the header.

Apparently that's too gross for him, just to support one little platform,
and an ifdef would make it depend even more heavily on existing machine
conditions. Sigh. Even with fixups I have a sneaking suspicion that it
wouldn't operate as desired because it'd be too busy printing out warning
messages.

		--Robby