CORBA3 — Alignment for empty sequence?

struct X

;

The question is, how should things be padded if double_seq is empty?
(Assume that we are starting at byte offset 0 for marshaling this structure.)

Approach taken by ORB 1:

• long_1 is aligned on a four-byte boundary (offset 0).

• The length of double_seq is aligned on a four-byte boundary,
  immediately following long_1 (offset 4).

• long_2 is aligned on a four-byte boundary. Because double_seq is
  empty, this means that long_2 immediately follows the length of
  double_seq on the wire, so long_2 begins at offset 8 and the total
  number of bytes for the struct is 12.

Approach taken by ORB 2:

• long_1 is aligned on a four-byte boundary (offset 0).

• The length of double_seq is aligned on a four-byte boundary,
  immediately following long_1 (offset 4).

• Now four bytes of padding are inserted because the sequence element
  type is double, so the next data item is expected to start on
  an eight-byte boundary.

• long_2 is aligned on that eight-byte boundary, so long_2 begins at
  offset 12 and the total number of bytes for the struct is 16.

The spec isn't clear on what should happen:

Sequences are encoded as an unsigned long value, followed by the
elements of the sequence. The initial unsigned lon gcontains the
number of elements in the sequence. The elements of the sequence
are encoded as specified for their type.

>From this, I cannot infer unambiguously which interpretation is correct.

Both approaches seem reasonable. (Personally, I have a slight preference
toward approach 2 because it's more consistent: after consuming the sequence,
the next data item will always start on an 8-byte boundary, which is more
consistent than approach 1, because the padding rules don't depend on the
length of the sequence at run time.)

I suspect that the best way to resolve this might be to take a majority vote
in line with the behavior of current implementations. And, of course,
the question now is what do we do with the GIOP version? We probably should
increment it, but I don't see what that would achieve for already existing
implementations, sigh...

see above, no change necessary