Legacy Issue Number: 3096
Source: Camros Corporation ( Jeffrey Marshall)
In the current 2.3 spec section 15.3.3 on Encapsulation
states in the last paragraph:
"Note that this gaurantees a four-octet alignment of the
start of all encapsulated data within GIOP messages and
There's a foot note on the bottom of the page stating:
(2) "Accordingly, in cases where encapsulated data holds
data with natural alignment of greater than four
octets, some processors may need to copy the octet
data before removing it from the encapsulation. The
GIOP protocol itself does not require encapsulation
of such data"
Here's the problem, the latest revisions have added support
for a "[unsigned] long long" being the discriminator type
within a union and therefore the encapsulated information
for a tk_union TypeCode could have alignment needs of eight,
The footnote needs to be revised to indicate that copying
could be necessary for some type code indirections or at
least the sentence stating that "GIOP problem itself..."
should be removed/revised. Of course we could try to
remove support for "long long" discriminators....
Some of the interoperability testing we've been doing
indicates that all but one vendor who supports long long
discriminator types are not doing things correctly...
Reported: CORBA 2.3.1 — Tue, 7 Dec 1999 05:00 GMT
Disposition: Resolved — CORBA 2.4
to close with revision
Updated: Fri, 6 Mar 2015 20:58 GMT