Oppolzer - Informatik / Blog

To give you an example on the different alignment strategy of (for example)
PL/1 and C:

let's assume a structure

typedef struct
{
    short a;
    int b;
    short c;
    int d;
}
example;

in PL/1;

DCL 1 EXAMPLE,
      3 A BIN FIXED (15),
      3 B BIN FIXED (31),
      3 C BIN FIXED (15),
      3 D BIN FIXED (31);

These two definitions will not match, because:

in C there are two padding bytes after a and after c; the whole structure starts
at an address multiple of 4, because there are ints inside the structure.

In PL/1, B has to be on a 4 byte boundary.  To save padding bytes, the beginning
of the structure will be in the middle of a full word, that is:  on an offset
that has remainder 2 when divided by 4. So the offsets of the structure
components are different; when the structures are overlaid, the fields don't
match.

To get around this, we put dummy double precisions fields (with the highest
possible alignment needs) in the front of every such structure.  Then the
offsets and paddings of the remaining fields will be in sync.

(BTW:  if there are multiple instances of the PL/1 structure, for example in an
array, the PL/1 technique does not save anything, because the padding fields now
appear at the end of the structure ... before the next element begins).

Kind regards

Bernd



Am 23.02.2015 um 08:37 schrieb Bernd Oppolzer:
> Hello Z.,
>
> unless the structure is defined with the nonstandard extension Packed (or
> _Packed, I don't recall it exactly), all ints or longs will be aligned on a 4
> byte boundary, that is, in a sequence of int, short, int, short, you will get
> two padding bytes after every short field (which is in fact 2 bytes long).
>
> Same goes for PL/1 with a sequence of BIN FIXED(31) and BIN FIXED(15) fields.
> The rules for alignment with PL/1 are more complicated than with C. Structures
> in C always start with the highest needed alignment required inside the
> structure, while in PL/1 there is some work done to start the structure at an
> offset which minimizes the padding bytes in the middle of the structure (short
> story, the long explanation in the PL/1 books needs many pages).
>
> You can synchronize alignment between PL/1 and C, if you put a dummy double
> precision field (which has alignment requirement of 8) in front of the
> structure.  Then the two languages do the same.  A similar technique should work
> for COBOL, too.
>
> Kind regards
>
> Bernd
>
>
>
> Am 23.02.2015 um 03:44 schrieb Z.A.:
>> __off_t is clearly defined earlier as a 32 bit entity but mbstate_t
>> is defined as short which I assumed is a 16 bit entity.  Either short
>> is NOT 16 bits but 32 bit entity as well, or the C compiler leaves 2
>> bytes of zeroes in order to keep the correct integral boundary.
>> However, in REAL LIFE there are 32 bits between rm_so and rm_eo.  I
>> did not bother to investigate too much ...
>