Issue 3096: CDR Encapsulation Issue (interop) Source: Camros Corporation (Mr. Jeffrey A. Marshall, jam(at)camros.com) Nature: Uncategorized Issue Severity: 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... Resolution: to close with revision Revised Text: Change footnote 2 in 15.3.3 from: " 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. " to: " 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. For example, an appropriate way to deal with long long discriminator type in an encapsulation for a union TypeCode is to encode the body of the encapsulation as if it was aligned at the 8 byte boundary, and then copy the encoded value into the encapsulation. This may result in long long data values inside the encapsulation being aligned on only a 4 byte boundary when viewed from outside the encapsulation. " Actions taken: December 7, 1999: received issue October 4, 2000: closed issue Discussion: End of Annotations:===== Date: 7 Dec 1999 03:22:37 -0000 Message-ID: <19991207032237.23597.qmail@grub.paragon-software.com> From: "Jeffrey A. Marshall" To: interop@omg.org, issues@omg.org Subject: CDR Encapsulation Issue Reply-to: jam@camros.com X-Organization: Camros Corporation Content-Type: text X-UIDL: dJ5e9aPNe9i@9e96a#e9 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... -jeff ------------------- Jeffrey A. Marshall Camros Corporation Email jam@camros.com Voice 703-876-1700 ext. 10 Fax 703-876-1818 http://www.camros.com/ Sender: jbiggar@floorboard.com Message-ID: <384D59FC.77405ACA@floorboard.com> Date: Tue, 07 Dec 1999 11:03:24 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: jam@camros.com CC: interop@omg.org Subject: Re: CDR Encapsulation Issue References: <19991207032237.23597.qmail@grub.paragon-software.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: m > 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... I don't think you have the right interpretation. CDR encapsulations only guarantee 4 byte alignment of the encapsulation contents. The appropriate way to deal with long long in an encapsulation for the union TypeCode is to encode the body of the encapsulation as if it was aligned at the 8 byte boundary, and then copy the encoded value into the encapsulation. This may result in long long data values inside the encapsulation being aligned on only a 4 byte boundary when viewed from outside the encapsulation. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org From: jam@paragon-software.com Message-ID: <19991208014032.1609.qmail@grub.paragon-software.com> Subject: Re: CDR Encapsulation Issue To: jon@floorboard.com (Jonathan Biggar) Date: Tue, 7 Dec 1999 20:40:32 -0500 (EST) Cc: jam@camros.com, interop@omg.org Reply-To: jam@camros.com In-Reply-To: <384D59FC.77405ACA@floorboard.com> from "Jonathan Biggar" at Dec 7, 99 11:03:24 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-UIDL: 5mPd9LKl!!B5nd9j4O!! Jon, I understand what is supposed to happen -- the issue is that the current GIOP spec. explains this incorrectly. It states in the footnote that GIOP doesn't require the encapsulation of any data with alignment needs of greater than a four byte boundry. This is false, the type code encapsulation of a tk_union may require alignment of its case label values on an eight byte boundry. I think its important to state the above fact and remove/revise the incorrect last sentence in the foot note ((2), shown below). -jeff > > "Jeffrey A. Marshall" wrote: > > > > 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... > > I don't think you have the right interpretation. CDR encapsulations > only guarantee 4 byte alignment of the encapsulation contents. The > appropriate way to deal with long long in an encapsulation for the > union > TypeCode is to encode the body of the encapsulation as if it was > aligned > at the 8 byte boundary, and then copy the encoded value into the > encapsulation. This may result in long long data values inside the > encapsulation being aligned on only a 4 byte boundary when viewed > from > outside the encapsulation. > > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org > ------------------- Jeffrey A. Marshall Camros Corporation Email jam@camros.com Voice 703-876-1700 ext. 10 Fax 703-876-1818 http://www.camros.com/