🚀 go-pugleaf

In article <806@cbnewsl.ATT.COM> dfp@cbnewsl.ATT.COM (david.f.prosser) writes:
>I disagree here, Doug.  The pANS does allow for virtually any padding
>within structures, but when the initial portions of such type declarations
>are identical, they are guaranteed to match.  See section 3.3.2.3.

I thought that was what I said, although I may have gotten confused using
the names "c1", "c4", etc.  It is the "second half" of the composite
structure that may well cause problems, due to padding being inserted
between the first and second halves.  For example, if the first half was
supposed to map onto 3 chars and the second half ditto, an implementation
that always aligns structs on 4-byte boundaries would insert a pad byte
at the end of the first nominally 3-byte structure so that the second
member of the composite structure would be properly aligned.  Thus, if one
tried to map the composite structure onto a simple array of 6 chars (or
onto a simple structure with 6 consecutive char members), it wouldn't fit
properly past the third byte.

Structure padding is such a pain that I don't recommend using such an
approach in portable code.  Much better to roll the data bytes into a
simple array (or equivalent unpadded object), then construct the objects
represented by the raw data bytes through explicit assembly, e.g.
	n_params = data[2] | data[3]<<8 | data[4]<<16 | data[5]<<24;
There are non-portable ways to "cheat", in order to get slightly more
efficient code for this operation, but the odds are that the cost of doing
the input dwarfs the cost of assembling the desired objects, so there is
no appreciable gain from such "cheats".