Issue 3245: Construction of _var types (cxx_revision) Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com) Nature: Uncategorized Issue Severity: Summary: the spec says (on page 1-23): The T* constructor creates a T_var that, when destroyed, will delete the storage pointed to by the T* parameter. The parameter to this constructor should never be a null pointer. Compliant implementations are not required to detect null pointers passed to this constructor. This seems broken for two reasons: - In an environment without real exceptions, null pointers must be returned for variable-length types in the presence of an exception. So if I write Foo_var fv(some_ref->op(my_corba_environment)); and op() raises an exception (which will be returned in the environment), I'm hosed. - The assignment operator permits assignment of null, but the constructor doesn't. This is inconsistent, if nothing else. It seems that disallowing initialization from null pointer is some historical hangover? I think the restriction should be removed. Resolution: Revised Text: Actions taken: January 25, 2000: received sisue Discussion: deferred in June 2011 to the next RTF End of Annotations:===== Date: Tue, 25 Jan 2000 12:36:11 +1000 (EST) From: Michi Henning Reply-To: C++ Revision Task Force To: C++ Revision Task Force cc: issues@omg.org Subject: Construction of _var types Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: O!Ce9]:Rd9VI:e9!ih!! Hi, the spec says (on page 1-23): The T* constructor creates a T_var that, when destroyed, will delete the storage pointed to by the T* parameter. The parameter to this constructor should never be a null pointer. Compliant implementations are not required to detect null pointers passed to this constructor. This seems broken for two reasons: - In an environment without real exceptions, null pointers must be returned for variable-length types in the presence of an exception. So if I write Foo_var fv(some_ref->op(my_corba_environment)); and op() raises an exception (which will be returned in the environment), I'm hosed. - The assignment operator permits assignment of null, but the constructor doesn't. This is inconsistent, if nothing else. It seems that disallowing initialization from null pointer is some historical hangover? I think the restriction should be removed. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html X-Authentication-Warning: gendev.com: Host 1Cust253.tnt2.sacramento2.ca.da.uu.net [63.17.219.253] claimed to be ldfrankel Reply-To: From: "David Frankel" To: "Andrew Watson" , "Carol Burt" , "Jeff Mischkinsky" , "Tom Rutt" , "Jishnu Mukerji" , "Doug Locke" , "Sridhar Iyengar" , "Peter Walker" , "Michi Henning" , "Keith Duddy" Cc: , "Juergen Boldt" , "Fred Waskiewicz" , Subject: RE: OTS RTF interim report Date: Thu, 5 Oct 2000 12:52:34 -0500 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: text/plain; charset="us-ascii" X-UIDL: N,Y!!fJPe9E\%!!J7P!! I wish to get a clarification about the table entitled "POA Creation and IOR components" which is part of the new text that resolves issue 3245: Two of the columns are entitled "Result". The values in the rows for these columns are not the same, so the two columns are apparently intended to represent different sub-cases of "OTS-unaware ORB". What are these two subcases specifically and don't these two columns headings need to be different or am I missing something? --Dave ================================ David S. Frankel Chief Scientist Genesis Development Corporation An Iona Technologies' Company 741 Santiago Court Chico, CA 95973-8781 USA +1 530 893-1100 voice +1 530 893-1153 fax david.frankel@iona.com NOTE NEW EMAIL ADDRESS!! ================================