pragma Pack vs. Convention C, portability issue?

pragma Pack vs. Convention C, portability issue?

[okellogg]

-- 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;

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

[Adam Beneschan]

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

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

[Robert A Duff]

Adam Beneschan <adam@irvine.com> writes:

> 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.

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

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

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wcctzlmk5rg.fsf@shell01.TheWorld.com...
...
> Are there any Ada implementations that don't support the SP annex?

Yes.

But we do support most of the representation IA. (But *not* the packing IA).

                       Randy.

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

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wcctzlmk5rg.fsf@shell01.TheWorld.com...
...
> Are there any Ada implementations that don't support the SP annex?

Yes.

But we do support most of the representation IA. (But *not* the packing IA).

                       Randy.

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

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wcctzlmk5rg.fsf@shell01.TheWorld.com...
...
> Are there any Ada implementations that don't support the SP annex?

Yes.

But we do support most of the representation IA. (But *not* the packing IA).

                       Randy.

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

[Randy Brukardt]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:fm6qhc$v2o$1@jacob-sparre.dk...
> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
> news:wcctzlmk5rg.fsf@shell01.TheWorld.com...
> ...
> > Are there any Ada implementations that don't support the SP annex?
>
> Yes.
>
> But we do support most of the representation IA. (But *not* the packing
IA).

For those of you whom are tired of seeing me post the same message a zillion
times, I think I've figured out what the problem is (or might be, anyway).
It appears that the messages are getting sent to the server successfully,
but the connection is timing out before the reply come back. Of course, the
newsreader takes that as a failure and retries sending the message. It's a
similar problem as one I've recently debugged with sending e-mail to some
places in Europe -- the propagation delay can be very long and thus the
timeout needs to be extra long. I'm experimentally setting the timeout to 3
*minutes* to see if that will help; I hope it does.

                                     Randy.

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

[okellogg]

On Jan 9, 5:06 pm, Adam Beneschan <a...@irvine.com> wrote:
>
>    for Perhaps_Packed'Component_Size use 2;
>
Yes, this is what I've been overlooking.
Many thanks

  Oliver

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

[Randy Brukardt]

"okellogg" <okellogg@freenet.de> wrote in message
news:a244cc70-8735-468d-a0ad-b2b659b6d58e@v67g2000hse.googlegroups.com...
> -- File: main.adb
> -- Can we portably rely on pragma Pack taking precedence
> -- over Convention C?

The ARG has argued similar questions as part of AI05-0012. And when I say
argue, I meant it -- this was one of the most contentious issues that I can
remember in the ARG. About all we were able to agree on was that the
Implementation Advice for Pack requires things that are impossible. It got
bad enough that we tabled the AI completely; we're not planning to try to
resolve it in the near future.

One of the points of contention was that "best efforts" packing is good
enough (even when the IA says something else). Another point of contention
is whether the pragma should be rejected if "best efforts" packing causes
none at all.

Moral: avoid Pack for anything where the representation matters to
portability. Use 'Component_Size instead.

                                 Randy.

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

[(see below)]

On 11/1/08 04:20, in article fm8e95$q0u$1@jacob-sparre.dk,
"Randy Brukardt" <randy@rrsoftware.com> wrote:
> 
> Moral: avoid Pack for anything where the representation matters to
> portability. Use 'Component_Size instead.

What is the view on combinations like this:

   type seive is array (pos_integral range <>) of Boolean;
   for  seive'component_size use 8;
   pragma pack(seive);

or even this:

   type a_set is array (a_member) of Boolean;
   for  a_set'Component_Size use 1;
   pragma Pack(a_set);
   pragma Convention(C, Entity => a_set);

I guess these are somewhat redundant.
Does it matter?

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

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

[Adam Beneschan]

On Jan 11, 11:53 am, "(see below)" <yaldni...@blueyonder.co.uk> wrote:
> On 11/1/08 04:20, in article fm8e95$q0...@jacob-sparre.dk,
>
> "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>
> > Moral: avoid Pack for anything where the representation matters to
> > portability. Use 'Component_Size instead.
>
> What is the view on combinations like this:
>
>    type seive is array (pos_integral range <>) of Boolean;
>    for  seive'component_size use 8;
>    pragma pack(seive);
>
> or even this:
>
>    type a_set is array (a_member) of Boolean;
>    for  a_set'Component_Size use 1;
>    pragma Pack(a_set);
>    pragma Convention(C, Entity => a_set);

13.2(9) makes me think that the 'Component_Size clause is honored and
the Pack pragma can't change it.

                                 -- Adam

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

[Randy Brukardt]

"(see below)" <yaldnif.w@blueyonder.co.uk> wrote in message
news:C3AD79A1.D95EF%yaldnif.w@blueyonder.co.uk...
...
> What is the view on combinations like this:
>
>    type seive is array (pos_integral range <>) of Boolean;
>    for  seive'component_size use 8;
>    pragma pack(seive);

Send that to the Dept. of Redundancy Department.

The Pack has (and can have) no effect, so there is no reason to give it.
That was one of the points of contention: if the pragma can have no effect
because of some other reason (by-reference types, atomic types, other rep.
clauses), some of us thought it should be rejected (it seems to promise
something it can't deliver - just ignoring it seems harmful).

My preference is to avoid Pack altogether. (We probably took that too far
with Janus/Ada: we never even implemented it. ;-)

                               Randy.

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

[Robert A Duff]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> The ARG has argued similar questions as part of AI05-0012. And when I say
> argue, I meant it -- this was one of the most contentious issues that I can
> remember in the ARG.

Sometimes, it seems the contention is inversely proportional to
the importance of the topic.  ;-)

- Bob