Issue 1503: Typecode indirection issue (interop) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: We have come across the following issue with regard to typecode indirections. The specification states: the indirection is a numeric octet offset within the scope of some "top level" TypeCode and points to the TCKind value for the typecode. The question arrises then is it legal to point to the (possible) padding bytes preceeding the TCKind value or must the numberic value indicate the position of the actual TCKind value. If you assume the former then having rewound the required number of bytes you would word align before interogating the TCKind enum value. Resolution: Revised Text: Actions taken: June 4, 1998: received issue February 17, 1999: closed issue Discussion: End of Annotations:===== Return-Path: To: interop@omg.org Subject: typecode indirection question Date: Thu, 04 Jun 1998 14:16:50 +0100 From: Stephen McNamara We have come across the following issue with regard to typecode indirections. The specification states: the indirection is a numeric octet offset within the scope of some "top level" TypeCode and points to the TCKind value for the typecode. The question arrises then is it legal to point to the (possible) padding bytes preceeding the TCKind value or must the numberic value indicate the position of the actual TCKind value. If you assume the former then having rewound the required number of bytes you would word align before interogating the TCKind enum value. The offset value at byte number 292 (ffff ff5e) in the following message indicates an indirection of -162. Is this legal or should it be -160. A value of -162 points to byte position 130 which is 2 bytes of padding before the TCkind value 0000 0003. A value of -160 would point to position 132 which is the TCkind value 0000 0003 directly. 0: 4749 4f50 0100 0001 0000 2c88 0000 0000 GIOP......,..... 16: 0000 0000 0000 0000 0dbb 4c3a 0000 0013 ..........L:.... 32: 0000 000c 0072 3a31 0000 0006 0000 0000 .....r:1........ 48: 0000 0000 0000 0014 0000 000c 0000 0010 ................ 64: 0000 000b 0000 0002 0000 0010 0000 02cb ................ 80: 0039 0000 0000 0016 4944 4c3a 5065 6e74 .9......IDL:Pent 96: 6c61 6e64 4465 6c6c 313a 312e 3000 0000 landDell1:1.0... 112: 0000 000e 5065 6e74 6c61 6e64 4465 6c6c ....PentlandDell 128: 3100 0000 0000 0003 ffff ffff 0000 0004 1............... 144: 962c 68ec 0000 0009 526f 6f73 7465 7231 .,h.....Rooster1 160: 0000 0000 0000 0014 0000 01ec 0000 0000 ................ 176: 0000 0014 0000 01dc 0000 0000 0000 0014 ................ 192: 0000 01cc 0000 0000 0000 000f 0000 01bc ................ 208: 0000 0000 0000 0013 4944 4c3a 4272 617a ........IDL:Braz 224: 696c 4e75 7431 3a31 2e30 0000 0000 000b ilNut1:1.0...... 240: 4272 617a 696c 4e75 7431 0000 0000 0005 BrazilNut1...... 256: 0000 000c 5275 6e6e 6572 6265 616e 3100 ....Runnerbean1. 272: 0000 0008 0000 0006 546f 6675 3100 0000 ........Tofu1... 288: ffff ffff ffff ff5e 0000 0008 5072 756e .......^....Prun 292: ....... truncated I'm not sure if this is really an issue for the specification or are receivers of IIOP messages containing indirected typecodes simply required to perform this word alignment. I think the specification should make it clear whether indirection values are permitted to include padding bytes or not. stephen Return-Path: Sender: jon@floorboard.com Date: Thu, 04 Jun 1998 08:37:48 -0700 From: Jonathan Biggar To: Stephen McNamara CC: interop@omg.org Subject: Re: typecode indirection question References: <199806041316.OAA14521@green.aptest.ie> Stephen McNamara wrote: > > We have come across the following issue with regard to typecode > indirections. The specification states: > > the indirection is a numeric octet offset within the scope of > some > "top level" TypeCode and points to the TCKind value for the > typecode. > > The question arrises then is it legal to point to the (possible) > padding bytes preceeding the TCKind value or must the numberic value > indicate the position of the actual TCKind value. If you assume the > former then having rewound the required number of bytes you would > word > align before interogating the TCKind enum value. ... > I'm not sure if this is really an issue for the specification or are > receivers of IIOP messages containing indirected typecodes simply > required to perform this word alignment. I think the specification > should make it clear whether indirection values are permitted to > include padding bytes or not. Since the CDR Typecode parsing process in an ORB must be ready to skip the pad bytes whenever it is preparing to parse a TypeCode anyway, I don't see any particular reason to disallow the offset from pointing to the "pad" bytes before the TypeCode. It would be a good idea to mention that this is OK in the spec. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Thu, 04 Jun 1998 20:26:30 -0700 From: Jon Goldberg To: Jonathan Biggar CC: stephen@aptest.ie, interop@omg.org Subject: Re: typecode indirection question References: <199806041316.OAA14521@green.aptest.ie> Jonathan Biggar wrote: > > Stephen McNamara wrote: > > > > We have come across the following issue with regard to typecode > > indirections. The specification states: > > > > the indirection is a numeric octet offset within the scope of > some > > "top level" TypeCode and points to the TCKind value for the > > typecode. > > > > The question arrises then is it legal to point to the (possible) > > padding bytes preceeding the TCKind value or must the numberic > value > > indicate the position of the actual TCKind value. If you assume > the > > former then having rewound the required number of bytes you would > word > > align before interogating the TCKind enum value. > > ... > > > I'm not sure if this is really an issue for the specification or > are > > receivers of IIOP messages containing indirected typecodes simply > > required to perform this word alignment. I think the specification > > should make it clear whether indirection values are permitted to > > include padding bytes or not. > > Since the CDR Typecode parsing process in an ORB must be ready to > skip > the pad bytes whenever it is preparing to parse a TypeCode anyway, I > don't see any particular reason to disallow the offset from pointing > to > the "pad" bytes before the TypeCode. > > It would be a good idea to mention that this is OK in the spec. I would have no problem with saying that either offset is legal as it is a trivial computation to do make things "right" in the receiving ORB. It must be the case, however, that the properly aligned offset is OK and that either one can be used in a given request. -Jon