Issue 750: Setting the value of a DynAny after calling rewind() may be harmful (port-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Minor Summary: Summary: Instead of making implementations of DynAny more complex, we suggest to clarify that calling rewind() to set the value associated a DynAny object may lead to unpredictable results. It should also be specified that rewind() is only safe if used to re-read components associated to DynAny or re-write components associated to a DynAny if the type associated to DynAny remains the same and that it is of fixed length Resolution: Revised Text: Actions taken: October 6, 1997: received issue Discussion: End of Annotations:===== Return-Path: Date: Mon, 6 Oct 1997 11:44:06 -0600 From: Juan Hierro Subject: Yet another three issues (the lasts, I promise !) To: juergen@omg.org Cc: jhierro@ovdm36.cnd.hp.com Content-Md5: k1zAVq2huoVvGDsUtg6OHQ== DynAny issues: ============== Title: Setting the value of a DynAny after calling rewind() may be harmful Description: One programmer may decide to create a dynany, initialize it with some value and then call rewind() trying to initialize it again. If the value associated to the DynAny corresponds to a constructed value which is of variable length, there may be problems trying to assign a value which is longer in size to the previous one. Instead of making implementations of DynAny more complex, we suggest to clarify that calling rewind() to set the value associated a DynAny object may lead to unpredictable results. In addition, we should specify that rewind() is only safe if used to re-read components associated to a DynAny or re-write components associated to a DynAny if the type associated to the DynAny remains the same and the it is of fixed length. Sender: jis@fpk.hp.com Message-ID: <380E0D89.4A24A8C@fpk.hp.com> Date: Wed, 20 Oct 1999 14:44:25 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) MIME-Version: 1.0 To: orb_revision@omg.org Subject: Issue 750 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: *iW!!WJT!!&HG!!"!o!! Do we need to do anything about this or should we just close it no change? Issue 750: Setting the value of a DynAny after calling rewind() may be harmful (port-rtf) Click here for this issue's archive. Source: Telefonica I+D (Sr. Juan J. Hierro, jhierro@tid.es) Nature: Uncategorized Issue Severity: Minor Summary: Instead of making implementations of DynAny more complex, we suggest to clarify that calling rewind() to set the value associated a DynAny object may lead to unpredictable results. It should also be specified that rewind() is only safe if used to re-read components associated to DynAny or re-write components associated to a DynAny if the type associated to DynAny remains the same and that it is of fixed length Possible alternative ways of resolving this issue are: 1) No change, 2) Add the following sentence in the middle of page 9-15, immediately preceding the para that begins "The next operation....": "Rewind (and seek) are intended for use primarily to access fields in an existing DynAny. Attempt to use these operations and then to change the contents of the field thus indexed may lead to unpredictable results" Need advice from experts on which path to take. Thanks, Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Sender: jon@floorboard.com Message-ID: <380E1FB5.D007D0AD@floorboard.com> Date: Wed, 20 Oct 1999 13:01:57 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Jishnu Mukerji CC: orb_revision@omg.org Subject: Re: Issue 750 References: <380E0D89.4A24A8C@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 61 > Do we need to do anything about this or should we just close it no > change? > > Issue 750: Setting the value of a DynAny after calling rewind() may > be harmful > (port-rtf) > > Click here for this issue's archive. > Source: Telefonica I+D (Sr. Juan J. Hierro, jhierro@tid.es) > Nature: Uncategorized Issue > Severity: Minor > Summary: Instead of making implementations of DynAny more complex, > we suggest to > clarify that calling rewind() to set the value associated a DynAny > object > may lead to unpredictable results. It should also be specified that > rewind() is > only safe if used to re-read components associated to DynAny or > re-write > components associated to a DynAny if the type associated to DynAny > remains the > same and that it is of fixed length > > Possible alternative ways of resolving this issue are: > > 1) No change, > > 2) Add the following sentence in the middle of page 9-15, > immediately preceding > the para that begins "The next operation....": > > "Rewind (and seek) are intended for use primarily to access fields > in an > existing DynAny. Attempt to use these operations and then to change > the contents > of the field thus indexed may lead to unpredictable results" > > Need advice from experts on which path to take. It's certainly feasible to implement DynAny without this proposed restriction, although obviously more complex. I say close with no change. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 20 Oct 1999 13:52:07 PDT Sender: Bill Janssen From: Bill Janssen To: Jishnu Mukerji , Jonathan Biggar Subject: Re: Issue 750 CC: orb_revision@omg.org In-Reply-To: <380E1FB5.D007D0AD@floorboard.com> References: <380E0D89.4A24A8C@fpk.hp.com> <380E1FB5.D007D0AD@floorboard.com> Content-Type: text X-UIDL: ~Y9e9:>(!!_WNd9b"D!! Excerpts from local.omg: 20-Oct-99 Re: Core RTF Workplan Jonathan Biggar@floorboa (2430*) > Since this subject comes up now and again, we should add a statement to > the spec that clarifies that Object has no repository id, doesn't need > one, and never will get one. :-) I'd rather specify one, and point out that at least at CORBA 2.3 it isn't really used for anything. We don't know in what coils future RFPs will enmesh us. Bill Sender: jon@floorboard.com Message-ID: <380E318F.ED3C3066@floorboard.com> Date: Wed, 20 Oct 1999 14:18:07 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Bill Janssen CC: Jishnu Mukerji , orb_revision@omg.org Subject: Re: Issue 750 References: <380E0D89.4A24A8C@fpk.hp.com> <380E1FB5.D007D0AD@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: kNGe9g>6!!nCKe9GoMe9 Bill Janssen wrote: > > Excerpts from local.omg: 20-Oct-99 Re: Core RTF Workplan Jonathan > Biggar@floorboa (2430*) > > > Since this subject comes up now and again, we should add a > statement to > > the spec that clarifies that Object has no repository id, doesn't > need > > one, and never will get one. :-) > > I'd rather specify one, and point out that at least at CORBA 2.3 it > isn't really used for anything. We don't know in what coils future > RFPs > will enmesh us. Isn't it better to stomp on it and make sure it is dead now, than have it come up again and again because someone didn't understand? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 20 Oct 1999 15:03:27 PDT Sender: Bill Janssen From: Bill Janssen To: Bill Janssen , Jonathan Biggar Subject: Re: Issue 750 CC: Jishnu Mukerji , orb_revision@omg.org In-Reply-To: <380E318F.ED3C3066@floorboard.com> References: <380E0D89.4A24A8C@fpk.hp.com> <380E1FB5.D007D0AD@floorboard.com> <380E318F.ED3C3066@floorboard.com> Content-Type: text X-UIDL: ]Gdd948#"!-7]d9^iYd9 Excerpts from local.omg: 20-Oct-99 Re: Issue 750 Jonathan Biggar@floorboa (679*) > > I'd rather specify one, and point out that at least at CORBA 2.3 it > > isn't really used for anything. We don't know in what coils future RFPs > > will enmesh us. > Isn't it better to stomp on it and make sure it is dead now, than have > it come up again and again because someone didn't understand? That's my point. There's no way to `make sure it is dead'. CORBA::Object is a type, and it's useful to model it as a type, at least internally, and it should have a type ID, and my bet is that someone sometime in some RFP response is going to come up with a need for the the type ID of CORBA::Object, and I'd prefer it not to be an empty string. Bill Date: Thu, 21 Oct 1999 12:16:12 +1000 (EST) From: Michi Henning X-Sender: michi@bobo.triodia.com To: Jishnu Mukerji cc: orb_revision@omg.org Subject: Re: Issue 750 In-Reply-To: <380E0D89.4A24A8C@fpk.hp.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Gj!e9LRNe9:VU!![fn!! On Wed, 20 Oct 1999, Jishnu Mukerji wrote: > Issue 750: Setting the value of a DynAny after calling rewind() may be harmful > (port-rtf) > > > 2) Add the following sentence in the middle of page 9-15, immediately preceding > the para that begins "The next operation....": Yes, leave it alone. Besides, the argument in the issue doesn't apply, I think. Assignment is a well-defined concept for DynAny, and the variable-length value argument does not apply either, as far as I can see. If the DynAny is for string, the usual memory management activities take place; if the DynAny is for a sequence, extending or otherwise changing the sequence also has well-defined semantics. Besides, if rewind() has a problem, seek() would, by definition, have at least the problems of rewind()... I suggest to close without change. Cheers, Michi. -- Michi Henning +61 7 3236 1633 Object Oriented Concepts +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@ooc.com.au AUSTRALIA http://www.ooc.com