-
Key: CORBA24-142
-
Legacy Issue Number: 3096
-
Status: closed
-
Source: Camros Corporation ( Jeffrey Marshall)
-
Summary:
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
nested encapsulations(2)"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,
not four.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
-
Disposition Summary:
to close with revision
-
Updated: Fri, 6 Mar 2015 20:58 GMT