Address error quietly fixed on 680x0 systems

[Ian Wilson]

A piece of code I inherited recently contained the fragment:

	*((INT_16 *) charbuf_p) = x; charbuf_p += sizeof(INT_16);

where charbuf_p had no alignment restrictions enforced, including
no restriction on being an odd address. To my surprise, this turns
out to work on 680x0 systems, both Sun3 and a vanilla Mac.

Looking at the code generated by cc I see a long move: no smarts
in the compiler therefore. So the only mechanism that I can be fixing
this is an address error trap that quietly moves unaligned objects
byte-by-byte as requested.

Simple timing experiments on the Sun3 don't appear to bear this out,
however; I saw a 50% increase in runtime with writes to an odd address
but would have expected more (the trap mechanisms on the 68k aren't
super fast after all). Enlightenment?

I readily agree that code fragments like the above are to be avoided;
here is my offering in the name of portability: improvements welcomed.
(Note: checks on buffer size exceeded omitted for clarity).

#define WRITE_ANY(x, type) /* eg. WRITE_ANY(f, float) */ \
  { type temp = (type) x; \
	char *cp  = (char *) &temp; \
	size_t n = sizeof(type); \
	do { *charbuf_p++ = *cp++; } while( --n ); }

 -- ian wilson

 PS. the strange loop construct was the only way we could find
	 to get Greenhills C to use `dbf' -- a year or so back though.