Re: pragma Pack vs. Convention C, portability issue?

[Adam Beneschan <adam@irvine.com>]

On Jan 9, 12:40 am, okellogg <okell...@freenet.de> wrote:
> -- File: main.adb
> -- Can we portably rely on pragma Pack taking precedence
> -- over Convention C?
> with Text_IO;
>
> procedure Main is
>
>    type C_Represented_Enum is (Zero, One, Two, Three);
>    pragma Convention (C, C_Represented_Enum);
>    -- This would be 32 bits on a 32 bit architecture
>
>    type Perhaps_Packed is array (1 .. 4) of C_Represented_Enum;
>    pragma Pack (Perhaps_Packed);
>    -- This could be either 8 bits if the compiler lets pragma Pack
>    -- take precedence over Convention C, or 4 * 32 = 128 bits
>    -- otherwise.
>
> begin
>    Text_IO.Put_Line
>      ("Perhaps_Packed'Size is" &
>       Natural'Image (Perhaps_Packed'Size));
> end Main;

In general, you can't rely on the Pack pragma to be portable at all;
implementations are free to ignore it if they choose, or to choose
whatever representation they think is best, without rejecting your
program.  In your example, it's possible for Perhaps_Pack'Size to be
32 if the compiler decides to make each element 8 bits.

The Implementation Advice for the Pack pragma says that "the
implementation should try to minimize storage allocated to objects of
the type, possibly at the expense of speed of accessing components,
subject to reasonable complexity in addressing calculations".  Of
course, this is just "advice", and an Ada implementation doesn't need
to follow it.  If it does follow the Advice, then I believe the
compiler should normally make each component two bits, but the Advice
is "flexible" enough that the compiler could make the components 8
bits or 16 bits or something else if it chooses.

If you really need the components to be two bits each, rather than
letting the compiler use its "judgment" between minimizing storage
size and reasonable speed, you're better off using a Component_Size
clause:

   for Perhaps_Packed'Component_Size use 2;

Assuming that the "word size" is divisible by 2 (and I haven't seen
any computers with a 19-bit word size for quite some time now :), then
the implementation should implement this with no gaps between the 2-
bit components, which means that the array would be 8 bits.  If for
some reason it doesn't support this, it will reject the program.
Note, though, that 13.3(72) says that an implementation doesn't need
to support Component_Sizes that are less than the size of the
component subtype.

In any case, to answer a question I think you're asking:

The Component_Size of an array *may* be less than the Size of the
component subtypes.  Thus, if your Convention pragma makes
C_Represented_Enum'Size equal to 32, this does not *prevent* the
compiler from making the Component_Size of the array type 2 (whether
with a Component_Size clause or a Pack pragma).  Convention does not
take "precedence" over Pack (or a Component_Size clause), the way you
asked it.  Whether the compiler actually makes the component size 2 or
not is implementation-dependent, but I think most compilers would.
They're definitely allowed to.

Hope this helps,

                                -- Adam