Issue 4007: wchar alignment in GIOP 1.2 (interop) Source: Borland Software Corporation (Mr. Vishy Kasar, nobody) Nature: Uncategorized Issue Severity: Summary: I have a question on the octet alignment requirement for wchar as mentioned in Table 15-1 of CORBA 2.3. In 15.3.1.6 the spec states that "For GIOP version 1.2, wchar is encoded as an unsigned binary octet value followed by the octet sequence representing the encoded value of the wchar. The initial octet contains a count of the number of elements in the sequence and the elements of the sequence of octets represent the wchar, using the negotiated wide character encoding" If this is a variable length octet sequence anyway, specifying an octet alignment for this does not make sense. Our assumption is that alignment is specified only for GIOP 1.1 style wchars and is irrelevant for GIOP 1.2 style wchars. I am looking for confirmation of that assumption. If that is a valid assumption, shall we change the table 15.1 third row first column entry to state "wchar (in GIOP 1.1)" instead of "wchar"? If that is not a valid assumption, what are we aligning here? The length byte? The elements of octet sequence? What is the benefit of any aligning in this case? Resolution: Close with revision Revised Text: In table 15.1 third row first colum entry: change: " wchar 1, 2 or 4 depending on codeset " to "wchar 1, 2 or 4 for GIOP 1.1 | 1 for GIOP 1.2 " Actions taken: October 31, 2000: received issue February 27, 2001: closed issue Discussion: Close with revision Agree with change to table 15.1. The use of a single octet for the length was originally proposed to facillitate octet alignment of wchar encoding. End of Annotations:===== Sender: "Vishy Kasar" Message-ID: <39FE2543.F76AD100@inprise.com> Date: Mon, 30 Oct 2000 17:49:55 -0800 From: Vishy Kasar Organization: Inprise Corporation - Visibroker Development X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: interop@omg.org Subject: wchar alignment in GIOP 1.2 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: nn=e9?_k!!n@#!!R6\!! I have a question on the octet alignment requirement for wchar as mentioned in Table 15-1 of CORBA 2.3. In 15.3.1.6 the spec states that "For GIOP version 1.2, wchar is encoded as an unsigned binary octet value followed by the octet sequence representing the encoded value of the wchar. The initial octet contains a count of the number of elements in the sequence and the elements of the sequence of octets represent the wchar, using the negotiated wide character encoding" If this is a variable length octet sequence anyway, specifying an octet alignment for this does not make sense. Our assumption is that alignment is specified only for GIOP 1.1 style wchars and is irrelevant for GIOP 1.2 style wchars. I am looking for confirmation of that assumption. If that is a valid assumption, shall we change the table 15.1 third row first column entry to state "wchar (in GIOP 1.1)" instead of "wchar"? If that is not a valid assumption, what are we aligning here? The length byte? The elements of octet sequence? What is the benefit of any aligning in this case? -- Cheers! Sender: jon@corvette.floorboard.com Message-ID: <39FE3EBD.9372DC2F@floorboard.com> Date: Mon, 30 Oct 2000 19:38:37 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Vishy Kasar CC: interop@omg.org Subject: Re: wchar alignment in GIOP 1.2 References: <39FE2543.F76AD100@inprise.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: K\Z!!"*U!!BlBe9E@%!! Vishy Kasar wrote: > > I have a question on the octet alignment requirement for wchar as > mentioned in Table 15-1 of CORBA 2.3. In 15.3.1.6 the spec states that > > "For GIOP version 1.2, wchar is encoded as an unsigned binary octet > value followed by the octet sequence representing the encoded value of > the wchar. The initial octet contains a count of the number of elements > in the sequence and the elements of the sequence of octets represent the > wchar, using the negotiated wide character encoding" > > If this is a variable length octet sequence anyway, specifying an octet > alignment for this does not make sense. Our assumption is that alignment > is specified only for GIOP 1.1 style wchars and is irrelevant for > GIOP 1.2 style wchars. I am looking for confirmation of that assumption. > > If that is a valid assumption, shall we change the table 15.1 third row > first column entry to state "wchar (in GIOP 1.1)" instead of "wchar"? > > If that is not a valid assumption, what are we aligning here? The length > byte? The elements of octet sequence? What is the benefit of any > aligning in this case? Yes, I think the table needs to be changed to say "1, 2 or 4 for GIOP 1.1/1 for GIOP 1.2". -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Tue, 31 Oct 2000 14:01:05 +1000 (EST) From: Michi Henning To: Vishy Kasar cc: interop@omg.org Subject: Re: wchar alignment in GIOP 1.2 In-Reply-To: <39FE2543.F76AD100@inprise.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Hmid9Ln:!!/&N!!RIVd9 On Mon, 30 Oct 2000, Vishy Kasar wrote: > I have a question on the octet alignment requirement for wchar as > mentioned in Table 15-1 of CORBA 2.3. In 15.3.1.6 the spec states > that > > "For GIOP version 1.2, wchar is encoded as an unsigned binary octet > value followed by the octet sequence representing the encoded value > of > the wchar. The initial octet contains a count of the number of > elements > in the sequence and the elements of the sequence of octets represent > the > wchar, using the negotiated wide character encoding" > > If this is a variable length octet sequence anyway, specifying an > octet > alignment for this does not make sense. Our assumption is that > alignment > is specified only for GIOP 1.1 style wchars and is irrelevant for > GIOP 1.2 style wchars. I am looking for confirmation of that > assumption. That's my impression too. There should not be any need to align the wide character or its preceding count octet on any particular boundary. > If that is a valid assumption, shall we change the table 15.1 third row > first column entry to state "wchar (in GIOP 1.1)" instead of "wchar"? That sounds like a reasonable change. Cheers, Michi.