Issue 116: Typecodes for recursive sequences (orb_revision) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: In the interface for the create_recursive_sequence_tc ORB method, is this just a matter of creating a TypeCode with these two fields, or is there a parameter missing? Resolution: No parameter is missing. you just create a TypeCode with TCKind set to tk_sequence and content type Revised Text: Replace the text in section 8.7.3 that says: Actions taken: September 13, 1996: Received issue February 23, 1999: closed issue Discussion: End of Annotations:===== Return-Path: Date: Fri, 03 Jul 1998 10:19:58 -0400 From: Jonathan Biggar Organization: Floorboard Software To: jis@fpk.hp.com, orb_revision@omg.org Subject: My votes for Vote #1 I vote yes on all issues, except for the following (with explanations): #116 It would be good to have an example in the spec, since this is a constant source of questions. If noone wants to write an example, then just change my vote to yes. #444 I think what the issue proposal was trying to say is that conforming compilers may support additional non-standard pragmas, but must ignore any pragma that the compiler does not understand without issuing an error (a warning would be ok). -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: X-Sender: vinoski@mail.boston.iona.ie Date: Fri, 24 Jul 1998 19:56:28 -0400 To: orb_revision@omg.org From: Steve Vinoski Subject: an issue with issue 116 The proposed-and-already-voted-for resolution to issue 116 in Vote 3 should have also included valuetype as a source of sequence recursion. After all, I assume the following is legal: valuetype V { public sequence seq; }; If it's not too late, I propose that the adopted resolution should be changed as shown below, and then re-adopted. :-) If it's too late to change it, let me know and I will file a new issue about it. --steve The create_recursive_sequence_tc operation is used to create TypeCodes describing recursive sequences that are members of structs, unions, or valuetypes. The result of this operation should be used as the typecode in the StructMemberSeq, UnionMemberSeq, or ValueMemberSeq arguments of the create_struct_tc, create_union_tc, or create_valuetype_tc operations respectively. The offset parameter specifies which enclosing struct, union, or valuetype is the target of the recursion, with the value one indicating the most immediate enclosing struct, union, or valuetype, and larger values indicating successive enclosing structs, unions, or valuetypes. For example, the offset would be one for the following IDL structure: struct foo { long value; sequence chain; }; Once the recursive sequence TypeCode has been properly embedded in its enclosing TypeCodes, it will function as a normal sequence TypeCode. Invoking operations on the recursive sequence TypeCode before it has been embedded in the required number of enclosing TypeCodes will result in undefined behavior. Return-Path: Sender: jon@floorboard.com Date: Fri, 24 Jul 1998 19:48:51 -0700 From: Jonathan Biggar To: Steve Vinoski CC: orb_revision@omg.org Subject: Re: an issue with issue 116 References: <4.0.1.19980724195044.01106150@mail.boston.iona.ie> Steve Vinoski wrote: > > The proposed-and-already-voted-for resolution to issue 116 in Vote 3 > should > have also included valuetype as a source of sequence > recursion. After all, > I assume the following is legal: > > valuetype V { > public sequence seq; > }; > > If it's not too late, I propose that the adopted resolution should > be > changed as shown below, and then re-adopted. :-) If it's too late to > change > it, let me know and I will file a new issue about it. I suppose it's not too late if you can get enough votes before next Thursday. But to address the technical question, I don't see any mention of allowing recursive sequence TypeCodes to reference valuetypes in the OBV submission. There is a separate mechanism for filling in recursions in valuetype TypeCodes. So I don't think this was oversight. Instead you are proposing a semantic change. That doesn't stop you from trying to get this changed in a vote ASAP or raising a new issue, of course. However there is actually a more serious bug in the proposal that Bob Kukura pointed out and we all forgot: // IDL struct Foo { sequence < sequence > m; }; This was legal for CORBA 2.2, and probably used an offset of 2. The new text in the proposal only allows struct and unions as enclosing typecodes because I thought that was all that was possible. The proposal should be rewritten like this (still without valuetype): Replace the text in section 8.7.3 that says: The create_recursive_sequence_tc operation is used to create TypeCodes describing recursive sequences. The result of this operation is used in constructing other types, with the offset parameter determining which enclosing TypeCode describes the elements of this sequence. For instance, to construct a TypeCode for the following OMG IDL structure, the offset used when creating its sequence TypeCode would be one: struct foo { long value; sequence chain; }; with: The create_recursive_sequence_tc operation is used to create TypeCodes describing recursive sequences that are members of structs or unions. The result of this operation should be used to construct a TypeCode in the StructMemberSeq or UnionMemberSeq arguments of the create_struct_tc or create_union_tc operations. The offset parameter specifies which enclosing struct or union TypeCode is the target of the recursion, with the value one indicating the most immediate enclosing TypeCode (which may be a struct, union, array or sequence), and larger values indicating successive enclosing TypeCodes. Using an offset that does not refer to a struct or union TypeCode results in undefined behavior. For example, the offset would be one for the following IDL structure: struct foo { long value; sequence chain; }; Once the recursive sequence TypeCode has been properly embedded in its enclosing TypeCodes, it functions as a normal sequence TypeCode. Invoking operations on the recursive sequence TypeCode before it has been embedded in the required number of enclosing TypeCodes results in undefined behavior. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: X-Sender: vinoski@mail.boston.iona.ie Date: Sun, 26 Jul 1998 10:23:20 -0400 To: obv-rtf@omg.org, orb_revision@omg.org From: Steve Vinoski Subject: Re: TypeCode replacement proposal There is an issue in my valuetype TypeCode proposal with recursive TypeCode offsets. I've also copied the ORB RTF as the solution is based on their recent adoption of a clarification for issue 116, also involving recursive TypeCodes. At 07:50 PM 7/24/98 -0400, I wrote: >The offset parameter specifies which >enclosing valuetype is the target of the recursion, with the value >one indicating the most immediate enclosing valuetype, and larger values >indicating successive enclosing valuetypes. For example, the offset would >be two for the A valuetype defined below: > >valuetype A; >valuetype B { > public A a_val; >}; >valuetype C { > public B b_val; >}; >valuetype A { > public C c_val; >}; If the offset is supposed to be one for the most immediate enclosing TypeCode, then I believe the offset for valuetype A should be three, not two. However, I think that for valuetypes, the most immediate enclosing TypeCode should be specified using an offset of zero, not one, which would make the original assessment of the offset being two for A correct. My reasoning is that for a recursion involving sequences, the offset to the immediate enclosing type is specified as being one. The example given in the Core is something like: struct X { sequence m; }; If we count the TypeCodes outward, we get: sequence TypeCode is at offset 0 struct X TypeCode is at offset 1 Bob Kukura recently pointed out that the offset would be two for this struct: struct X { sequence< sequence > m; }; If we count the TypeCodes outward, we get: sequence TypeCode is at offset 0 sequence< sequence > TypeCode is at offset 1 struct X TypeCode is at offset 2 So far, so good. Now let's look at a recursive valuetype that has an immediate member of its own type: valuetype V { public V m; }; If we count the TypeCodes outward, we get: valuetype V TypeCode is at offset 0 There is no sequence TypeCode to deal with, so the offset is 0. If my logic on this is correct, I would like to augment my original valuetype TypeCode proposal by adding the following after the valuetype A,B,C example: For a valuetype that directly contains a member of its own type, as shown below, the offset is zero. valuetype V { public V member; }; That's the end of my proposed addition. If you disagree with my logic, please point out where I went wrong. Also, if I am wrong, the ORB RTF might need to reevaluate its adopted clarification for issue 116. thanks, --steve Return-Path: X-Sender: vinoski@mail.boston.iona.ie Date: Sun, 26 Jul 1998 12:04:53 -0400 To: jon@floorboard.com From: Steve Vinoski Subject: Re: an issue with issue 116 Cc: orb_revision@omg.org [I originally sent this response on Friday but neither Jon nor I received it, so I'm resending.] At 07:48 PM 7/24/98 -0700, Jonathan Biggar wrote: >> The proposed-and-already-voted-for resolution to issue 116 in Vote >> 3 should >> have also included valuetype as a source of sequence >> recursion. After all, >> I assume the following is legal: >> >> valuetype V { >> public sequence seq; >> }; > >I suppose it's not too late if you can get enough votes before next >Thursday. But to address the technical question, I don't see any >mention of allowing recursive sequence TypeCodes to reference >> valuetypes >in the OBV submission. There is a separate mechanism for filling in >recursions in valuetype TypeCodes. So I don't think this was >oversight. Instead you are proposing a semantic change. That >> doesn't >stop you from trying to get this changed in a vote ASAP or raising a >> new >issue, of course. If people feel that this is a semantic change, I'm willing to drop it. My brief reading of the OBV grammar suggests that this is legal, but I could be wrong as I literally only glanced at it. To create a TypeCode for the recursive sequence valuetype shown above, you wouldn't use the create_recursive_valuetype_tc function -- you'd use the same old create_recursive_sequence_tc, and it would work just fine: TypeCode_var rtc = orb->create_recursive_sequence_tc(1, 0); ValueMemberSeq vmseq; vmseq.length(1); vmseq.name = CORBA::string_dup("seq"); vmseq.type = rtc; vmseq.access = PUBLIC_MEMBER; TypeCode_var tc = orb->create_valuetype_tc("IDL:V:1.0", "V", VTM_NONE, TypeCode::nil(), vmseq); Only if the valuetype had a valuetype of the same type as a member (either directly or indirectly) would you use the TypeCode creation functions for recursive valuetypes. After all, you use create_recursive_sequence_tc and create_struct_tc to create a TypeCode containing a sequence of that struct type, right? So, I don't see it as a semantic change at all -- it's really already supported in the specs, and I'm just pointing it out. (BTW, if you're not on the obv-rtf mailing list, you will not have seen my new proposal for the valuetype TypeCode creation operations, which I've used above. They're different than what's in orbos/98-01-18.) >However there is actually a more serious bug in the proposal that Bob >Kukura pointed out and we all forgot: > >// IDL > >struct Foo { > sequence < sequence > m; >}; > >This was legal for CORBA 2.2, and probably used an offset of 2. The new >text in the proposal only allows struct and unions as enclosing >typecodes because I thought that was all that was possible. The >proposal should be rewritten like this (still without valuetype): Bob and I were wondering what happened to this. I have two issues with your paragraph above: 1) As my explanation above shows, valuetype fits in here just fine. 2) Saying that ORBs "probably" used an offset of 2 is asking for trouble. Does anyone know what the answer *definitely* is? --steve Return-Path: Date: Sun, 26 Jul 1998 18:09:12 -0400 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard New Jersey Laboratories To: Steve Vinoski Cc: jon@floorboard.com, orb_revision@omg.org Subject: Re: an issue with issue 116 References: <199807261606.MAA12075@boston.iona.ie> Steve, Send this as a part of the TypeCode stuff for valuetype through the OBV RTF. OBV related issues are currently being handled by the OBV RTF and not by the Core RTF. Jeff and I then will figure out which pieces of text need to go in where, following isntructioins from you. Hope this is an acceptable way of handling this for all. Once the OBV RTF is wound up, then onwards we will allocated these issues according to how the new set of RTFs get setup. But for now please send all OBV related stuff through the OBV RTF. Thanks. Jishnu. Steve Vinoski wrote: > [I originally sent this response on Friday but neither Jon nor I received > it, so I'm resending.] > > At 07:48 PM 7/24/98 -0700, Jonathan Biggar wrote: > >> The proposed-and-already-voted-for resolution to issue 116 in Vote 3 should > >> have also included valuetype as a source of sequence recursion. After all, > >> I assume the following is legal: > >> > >> valuetype V { > >> public sequence seq; > >> }; > > > >I suppose it's not too late if you can get enough votes before next > >Thursday. But to address the technical question, I don't see any > >mention of allowing recursive sequence TypeCodes to reference valuetypes > >in the OBV submission. There is a separate mechanism for filling in > >recursions in valuetype TypeCodes. So I don't think this was > >oversight. Instead you are proposing a semantic change. That doesn't > >stop you from trying to get this changed in a vote ASAP or raising a new > >issue, of course. > > If people feel that this is a semantic change, I'm willing to drop it. My > brief reading of the OBV grammar suggests that this is legal, but I could > be wrong as I literally only glanced at it. > > To create a TypeCode for the recursive sequence valuetype shown above, you > wouldn't use the create_recursive_valuetype_tc function -- you'd use the > same old create_recursive_sequence_tc, and it would work just fine: > > TypeCode_var rtc = orb->create_recursive_sequence_tc(1, 0); > ValueMemberSeq vmseq; > vmseq.length(1); > vmseq.name = CORBA::string_dup("seq"); > vmseq.type = rtc; > vmseq.access = PUBLIC_MEMBER; > TypeCode_var tc = orb->create_valuetype_tc("IDL:V:1.0", "V", VTM_NONE, > TypeCode::nil(), vmseq); > > Only if the valuetype had a valuetype of the same type as a member (either > directly or indirectly) would you use the TypeCode creation functions for > recursive valuetypes. After all, you use create_recursive_sequence_tc and > create_struct_tc to create a TypeCode containing a sequence of that struct > type, right? So, I don't see it as a semantic change at all -- it's really > already supported in the specs, and I'm just pointing it out. > > (BTW, if you're not on the obv-rtf mailing list, you will not have seen my > new proposal for the valuetype TypeCode creation operations, which I've > used above. They're different than what's in orbos/98-01-18.) > > >However there is actually a more serious bug in the proposal that Bob > >Kukura pointed out and we all forgot: > > > >// IDL > > > >struct Foo { > > sequence < sequence > m; > >}; > > > >This was legal for CORBA 2.2, and probably used an offset of 2. The new > >text in the proposal only allows struct and unions as enclosing > >typecodes because I thought that was all that was possible. The > >proposal should be rewritten like this (still without valuetype): > > Bob and I were wondering what happened to this. I have two issues with your > paragraph above: > > 1) As my explanation above shows, valuetype fits in here just fine. > 2) Saying that ORBs "probably" used an offset of 2 is asking for trouble. > Does anyone know what the answer *definitely* is? > > --steve Return-Path: Sender: jon@floorboard.com Date: Sun, 26 Jul 1998 22:47:25 -0700 From: Jonathan Biggar To: jis@fpk.hp.com CC: Steve Vinoski , orb_revision@omg.org Subject: Re: an issue with issue 116 References: <199807261606.MAA12075@boston.iona.ie> <35BBA908.A0FCDAA9@fpk.hp.com> Jishnu Mukerji wrote: > > Steve, > > Send this as a part of the TypeCode stuff for valuetype through the > OBV RTF. OBV > related issues are currently being handled by the OBV RTF and not by > the Core RTF. > Jeff and I then will figure out which pieces of text need to go in > where, > following isntructioins from you. Hope this is an acceptable way of > handling this > for all. Once the OBV RTF is wound up, then onwards we will > allocated these issues > according to how the new set of RTFs get setup. But for now please > send all OBV > related stuff through the OBV RTF. I agree with Jishnu. By the way, I have no technical problem with the change, and after I took a look at your proposal on the obv-rtf mailing list, I'm glad you made it. The original OBV proposal for handling recursive valuetypes required modifying a TypeCode on the fly, which for some ORB architectures, was difficult to implement, if not impossible. Your proposal is right on the mark. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: X-Sender: vinoski@mail.boston.iona.ie Date: Sat, 25 Jul 1998 00:01:22 -0400 To: Jonathan Biggar From: Steve Vinoski Subject: Re: an issue with issue 116 Cc: orb_revision@omg.org References: <4.0.1.19980724195044.01106150@mail.boston.iona.ie> At 07:48 PM 7/24/98 -0700, Jonathan Biggar wrote: >Steve Vinoski wrote: >> >> The proposed-and-already-voted-for resolution to issue 116 in Vote 3 should >> have also included valuetype as a source of sequence recursion. After all, >> I assume the following is legal: >> >> valuetype V { >> public sequence seq; >> }; > >I suppose it's not too late if you can get enough votes before next >Thursday. But to address the technical question, I don't see any >mention of allowing recursive sequence TypeCodes to reference valuetypes >in the OBV submission. There is a separate mechanism for filling in >recursions in valuetype TypeCodes. So I don't think this was >oversight. Instead you are proposing a semantic change. That doesn't >stop you from trying to get this changed in a vote ASAP or raising a new >issue, of course. If people feel that this is a semantic change, I'm willing to drop it. My brief reading of the OBV grammar suggests that this is legal, but I could be wrong as I literally only glanced at it. To create a TypeCode for the recursive sequence valuetype shown above, you wouldn't use the create_recursive_valuetype_tc function -- you'd use the same old create_recursive_sequence_tc, and it would work just fine: TypeCode_var rtc = orb->create_recursive_sequence_tc(1, 0); ValueMemberSeq vmseq; vmseq.length(1); vmseq.name = CORBA::string_dup("seq"); vmseq.type = rtc; vmseq.access = PUBLIC_MEMBER; TypeCode_var tc = orb->create_valuetype_tc("IDL:V:1.0", "V", VTM_NONE, TypeCode::nil(), vmseq); Only if the valuetype had a valuetype of the same type as a member (either directly or indirectly) would you use the TypeCode creation functions for recursive valuetypes. After all, you use create_recursive_sequence_tc and create_struct_tc to create a TypeCode containing a sequence of that struct type, right? So, I don't see it as a semantic change at all -- it's really already supported in the specs, and I'm just pointing it out. (BTW, if you're not on the obv-rtf mailing list, you will not have seen my new proposal for the valuetype TypeCode creation operations, which I've used above. They're different than what's in orbos/98-01-18.) >However there is actually a more serious bug in the proposal that Bob >Kukura pointed out and we all forgot: > >// IDL > >struct Foo { > sequence < sequence > m; >}; > >This was legal for CORBA 2.2, and probably used an offset of 2. The new >text in the proposal only allows struct and unions as enclosing >typecodes because I thought that was all that was possible. The >proposal should be rewritten like this (still without valuetype): Bob and I were wondering what happened to this. I have two issues with your paragraph above: 1) As my explanation above shows, valuetype fits in here just fine. 2) Saying that ORBs "probably" used an offset of 2 is asking for trouble. Does anyone know what the answer *definitely* is? --steve