🚀 go-pugleaf

From article <9111051126.AA23603@robobar.Co.Uk>, by ronald@robobar.co.UK (Ronald S H Khoo):
> 
> In article <1991Nov4.183356.13191@midway.uchicago.edu>
>     pom2@quads.uchicago.edu wrote:
> 

	I'm going to insert a further, earlier quote from the same article:

>> [...] But on the Sparc2, SunOS 4.1.1, gcc and g++ pack the structures.

 (I think he means "pad" here -----------------------^)

>> Can gcc aquire a compilation switch that preserves structures on
>> machines where it is possible?
            ^^^^^^^^^^^^^^^^^^^^
(e.g. on Vaxen and '386s, but maybe not SPARCs)

> Microsoft C's #pragma pack() may do what you want.  volume 23 of
> comp.sources.misc contains a set of GCC patches used by XENIX users
> from which you can extract the few patch hunks required to teach gcc
> how to do Microsoft C's #pragma pack().

	All well and good, but... Unless I am gravely mistaken, SPARCs
need aligned data. Not that I couldn't hack up a version of gcc that picked
up each and every multi-byte datum one byte at a time, but I doubt anyone
would use it in preference to to, say, a Sun2 :-) Before you say "But you
would only have to hack the references to ints and long that were in
structures", think about:

#pragma pack 1
struct frazzle {
	char oops;
	long deadly;
} bait;

void
fred ( long *target ) {...}

int tom()
{
	fred( &bait.deadly );
}

	fred() must not assume that its parameter is an aligned pointer to
long. Possibly static analysis could reveal some cases that were "safe",
but I doubt it could help enough to be worth it.

						Mike

| Mike Albaugh (albaugh@dms.UUCP || {...motcsd.mot.com!}dms!albaugh)
| Atari Games Corp (Arcade Games, no relation to the makers of the ST)
| 675 Sycamore Dr. Milpitas, CA 95035		voice: (408)434-1709
| The opinions expressed are my own (Boy, are they ever)