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

Adam Beneschan <adam@xxxxxxxxxx> writes:

On Jan 9, 12:40 am, okellogg <okell...@xxxxxxxxxx> 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.

That's true, but for an implementation that claims to support the
Systems Programming Annex, the compiler is required by C.2(2) to
implement tight packing in many circumstances. Without the
Convention(C) above, Perhaps_Packed'Size must be 8 bits.

Are there any Ada implementations that don't support the SP annex?

With the Convention(C), I'm not sure what the right answer is.
I think what you say here:

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.

is probably right in that case.

I don't see why it matters, though. If you pass X(1), where X is of
type Perhaps_Packed, to a C function, it will be passed by copy,
so if it's 2 bits, it will get expanded into a 32-bit register
or some such.

If Perhaps_Pack were also Convention(C), then I suppose that would
defeat the packing -- it has to represent the array in a way the C
implementation likes.

- Bob
.

Relevant Pages

  • Re: padding mechanism in structures
    ... compiler options are inherently compiler specific. ... > data-declaration level by the pack pragma. ... > structure member after the first is stored on the smaller member type or ... If you use #pragma pack without an argument, ...
    (comp.lang.c)
  • Re: pragma Pack vs. Convention C, portability issue?
    ... -- Can we portably rely on pragma Pack taking precedence ... pragma Convention; ... -- This could be either 8 bits if the compiler lets pragma Pack ...
    (comp.lang.ada)
  • Re: Do not trust ALIGN
    ... #pragma pack ... Although I consider it a BUG in the compiler if those UNALIGNED atributes ... alignment of each member to it's native size. ...
    (microsoft.public.windowsce.platbuilder)
  • Re: Reading the while standard input into a String
    ... I certainly wouldn't use a compiler that didn't recognize pragmas such as ... The same goes for pragma Pack. ... The compiler can ignore pragma Pack in the sense that the compiler can allocate memory for the data type in the same was as if there were no pragma Pack. ... (Egil, please quote the relevant parts of the post to which you are replying! ...
    (comp.lang.ada)
  • Re: Why does #pragma pack fail to function?
    ... understand #pragma pack. ... or similar and not a #pragma. ... Those can be combined by the compiler into a single object of the ... I'll follow your advice from now on. ...
    (microsoft.public.vc.language)