pragma Pack does not work on GNAT 5.01a for Redhat Linux.

The Size of the following record is 112 on Linux, but 104 on Solaris.

type Something is record
   A : Packed_16;
   B : Packed_8;
   C : Packed_8;
   D : Packed_8;
   E : Packed_32;
   F : Packed_32;
end record;
pragma Pack (Something);

Where

type Packed_Byte is mod 2 **8;
for Packed_Byte'Size use 8;

type Packed_Bytes is array (Natural range <>) of Packed_Byte;
for Packed_Bytes'Alignment use 1;
for Packed_Bytes'Component_Size use Packed_Byte'Size;

type Packed_8 is new Packed_Bytes (0 .. 0);
for Packed_8'Size use 8;

and similar. Why is pragma Pack ignored?

TIA
/Petter

...

I don't think pragma Pack is ignored, there are "should"s in the RM
and then alignment. You might need a rep spec, though. Does this work?

   -- assume word size of 32 bits, 4 bytes
   wordsize: constant := 4;

   for Something use record
      A  at 0*wordsize range 0 .. 15;
      B  at 0*wordsize range 16 .. 23;
      C  at 0*wordsize range 24 .. 31;
      D  at 3*wordsize range 0 .. 7;
      E  at 1*wordsize range 0 .. 31;
      F  at 2*wordsize range 0 .. 31;
   end record;

   for Something'Size use 104;

We used to have rep spec's very early in a previous project, but one
of the other team members found that pragma Pack did the work as well
for Solaris, so we decided to do without rep specs. We thought it was
a good decision when the number of similar records increased over 500.
Now we are not so sure anymore. The before mentioned team member
thinks it is a bug and will probably submit a bug report to ACT.

As a former UNISYS employee, word size is always 36 ;-)

What happens if you add

for Something'Size use 104;

?

-- 
Jeff Carter
"Alms for an ex-leper!"
Monty Python's Life of Brian
75

Strange... I get 104 when I try it on Linux.  I could be using a
different version of GNAT, though.

                          -- Adam

package Test109pak is

    type Packed_Byte is mod 2 **8;
    for Packed_Byte'Size use 8;

    type Packed_Bytes is array (Natural range <>) of Packed_Byte;
    for Packed_Bytes'Alignment use 1;
    for Packed_Bytes'Component_Size use Packed_Byte'Size;

    type Packed_8 is new Packed_Bytes (0 .. 0);
    for Packed_8'Size use 8;

    type Packed_16 is new Packed_Bytes (0 .. 1);
    for Packed_16'Size use 16;

    type Packed_32 is new Packed_Bytes (0 .. 3);
    for Packed_32'Size use 32;

    type Something is record
       A : Packed_16;
       B : Packed_8;
       C : Packed_8;
       D : Packed_8;
       E : Packed_32;
       F : Packed_32;
    end record;
    pragma Pack (Something);

end Test109pak;

with Test109pak;
with Text_IO;
procedure Test109 is
begin
    Text_IO.Put_Line ("Size is " & Integer'Image
(Test109pak.Something'Size));
end Test109;

Are the processors different on the two systems? For some processors, the 
overhead for retrieving a 32-bit value that is not alligned on an even 
address or an address divisible by four could be enough higher that the 
default record layout will be different from what you experienced with 
Solaris. Then, depending on the interpretation of "storage minimization 
should be the main criterion when selecting the representation of a 
composite type" for pragma Pack in the RM, the packed layout may be 
different as well, since pragmas are only advice to the compiler. If you use 
a record representation clause, I would expect that if the compiler could 
not generate code to give you what you asked for, it would generate an 
error. You can use the 'size attribute to specify the overall record size, 
but then the compiler is still free to rearange the order of components to 
optimize storage and retrieval of the record components. For exchanging 
binary data between heterogeneous systems, my experience has been that 
record representation clauses are necessary to insure that the data 
representations are identical.

Regards,
Bob 

Absolutely.  You can't count on Pack to do things a certain way; the
RM says that the compiler is free to rearrange the components as it
sees fit to make things smaller.  Pack is appropriate when you want
the type to be as small as possible but don't really care how it's
laid out.  It's not appropriate if you care how your record is laid
out; you'll need a record rep clause for that.

                  -- Adam

"Bob Spooner" < XXXX@XXXXX.COM > writes:


Or (if on GNAT) you could use a version of the compiler's stream
support that uses XDR representations 'on the wire' -- we
transparently communicate between PowerPC and Intel hardware like this
as a matter of course without having to think about it or expend any
effort.

There's always a price to pay, of course; the packing isn't dense, and
it can be quite a challenge to work out what bytes are actually being
sent (eg, if you find yourself having to talk to C after all).

Yes, XDR takes care of things like endianness, etc. that otherwise get in 
the way, but as you point out, there's always a price to be paid for 
generality. In some cases it looks like it even will take care of differing 
floating point representations, although I wonder about out of range 
problems when converting. Isn't there an XDR library for C? I know that 
there is one for Fortran. I would think that as long as you have an XDR 
library for the language with which you need to communicate, you wouldn't 
have to decode the bytes yourself; or have I misunderstood what you are 
saying?

Bob 

"Bob Spooner" < XXXX@XXXXX.COM > writes:






For us that was a big 'if'. There was a scripting language that didn't
understand anything beyond bytes on the wire, so you had to be pretty
conversant with the actual layouts used by the Ada. We used an
ASIS-based tool to work this out, but it's not well integrated into
the build process. Fortunately message definitions on the interfaces
where it matters don't change very often.

Another problem was that the message header had to contain the length
of the message body -- the easiest way to do that is of course to
construct the body first! (or perhaps a dummy message body during
program initialization/elaboration?)

>>>>> "SW" == Simon Wright < XXXX@XXXXX.COM > writes:

    SW> "Bob Spooner" < XXXX@XXXXX.COM > writes:




    >>> 
    >>> There's always a price to pay, of course; the packing isn't dense, and
    >>> it can be quite a challenge to work out what bytes are actually being
    >>> sent (eg, if you find yourself having to talk to C after all).
    >> 
    >> Yes, XDR takes care of things like endianness, etc. that otherwise get in 
    >> the way, but as you point out, there's always a price to be paid for 
    >> generality. In some cases it looks like it even will take care of differing 
    >> floating point representations, although I wonder about out of range 
    >> problems when converting. Isn't there an XDR library for C? I know that 
    >> there is one for Fortran. I would think that as long as you have an XDR 
    >> library for the language with which you need to communicate, you wouldn't 
    >> have to decode the bytes yourself; or have I misunderstood what you are 
    >> saying?

C has had XDR and RPC at least since 1987. Try man xdr or man rpcgen on any unix
box. 

See

[Sun Microsystems
XDR: External Data Representation Standard
Internet Network Working Group
RFC1014 Internet Request For Comments, June 1987]

-- 
   C++: The power, elegance and simplicity of a hand grenade.

Ole-Hjalmar Kristensen < XXXX@XXXXX.COM > writes:


You seem to have snipped the last bit that I actually did say ..





True but not helpful if one side of the interface is implemented in
Ada and the other side uses just C and sockets (and you are on the Ada
side with no influence on the protocol). VxWorks both sides would
probably add to the fun.

I realise I didn't note these extra influences in my original remarks ..

Sorry for any confusion. My point was simply that XDR has been a de
facto standard available to C programmers for a very long time. If you
have an XDR library for Ada, you can exchange messages between C and
Ada programs with no problems, since the protocol is described in
terms of XDR, and not tided to any specific language.

-- 
   C++: The power, elegance and simplicity of a hand grenade.

Ole-Hjalmar Kristensen < XXXX@XXXXX.COM > writes:


As I said, if the C programmers concerned have decided not to use XDR
(perhaps they never heard of it? perhaps it's not available from their
RTOS supplier? perhaps they think the system is homogeneous, so why
bother?) then having an XDR library on the Ada side won't help.

I believe that AdaCore's XDR version of their System.Stream_Attributes
uses real XDR representations, anyway, so that part's easy!