Re: Why extra blanks in stat() IFS data structure?

On Mon, 15 Jul 2002 craigs@dekko.com wrote:
>
> Why the extra blanks in the stat() data structure for the stat() IFS API's?
>

Because of the way variables are aligned in C structures.   To make
things more efficient, 16-bit integers are aligned on 2-byte boundaries.
32-bit integers are aligned on 4 byte boundaries, 64-bit integers are
aligned on 8 byte boundaries, pointers are aligned on 16-byte boundaries,
etc, etc.

In RPG however, this type of alignment does not occur unless you use
the ALIGN keyword in your D-spec.

Take a look at the stat structure:

      D statDS          DS                  Based(p_statDS)
      D  st_mode                      10U 0
      D  st_ino                       10U 0
      D  st_nlink                      5U 0
      D  st_reserved1                  2A
      D  st_uid                       10U 0

st_mode goes from byte 1-4 of the structure.  st_ino goes from byte
5-8. They are aligned on 4-byte boundaries, since the offset from the
start of the memory allocations are 0 and 4 respectively.

Take st_nlink.  It is in positions 9-10 of the data structure, which is
at offset 8 from the start of the allocation.  Since 8 is a multiple of
2, that's okay.

but now, look at st_uid.  If it weren't for the st_reserved1 field, it
would end up at positions 11-14 of the structure.   That doesn't work,
because it's a 32-bit integer, and has to be on a 4-byte boundary.
Position 11 is a 10 byte offset from the start of the allocation.  Since
10 is not an even multiple of 4, the C compiler will not put it at offset
10, but will move it forward to the next 4-byte boundary.  i.e., it moves
it to offset 12...  positions 13-16 of the structure.

To duplicate that in RPG, you can use the ALIGN keyword on the D-spec.
However, the ALIGN keyword is a relatively new invention.  Before it
existed, you had to find another way of making the fields in the data
structure line up.

The way that we did that was to insert those "reserved" fields.  They
filled up the extra bytes, and pushed the field forward to where it
belonged.

Hope that makes sense...