[omniORB] Extraction of strings from Any

[David Riddoch]

Hi Luke,

Thank you for pursuing this issue, and pointing is to the definitive
answer.  We will modify behaviour of omniORB to comply with this latest
revision of the specification.  Talking of which, does anybody know what 
the status of this document is?  And anyone who can find this document
starting at the OMG's homepage gets my admiration.

Cheers,
David


On Tue, 25 May 1999,
Luke Tunmer wrote:

> Hi David,
> 
> I forwarded you argument to Michi Henning (whose book prompted me to look at
> this issue), and he's replied that the spec is now unarguably clear - the
> Any will look after the returned string and the caller should not free it.
> Below is his reply to my question.
> 
> The key sentence in the new spec is:
> 
> For non-primitive types such as struct, union, sequence, exception, string,
> wstring, and Any, extraction is done by pointer to const....
> 
> I'll be interested in hearing how and when Omni will deal with this
> clarification of the spec.
> 
> Many thanks,
> Luke
> 
> > -----Original Message-----
> > From: Michi Henning [mailto:michi@triodia.com]
> > Sent: 25 May 1999 12:14
> > To: Luke Tunmer
> > Subject: Re: Extracting strings from Any in C++
> >
> >
> > On Tue, 25 May 1999, Luke Tunmer wrote:
> >
> > > Since String is as primitive types, Omni claim that the extraction of a
> > > string is done by value semantics and therefore the caller
> > needs to free the
> > > memory.
> > >
> > > Clearly there's a disagreement over the interpretation of the
> > spec which is
> > > somewhat worrying. We have one important ORB vendor disagreeing with an
> > > authoritative book, which cannot be a good thing. Do you have
> > any insights
> > > into this? Should Omni change their implementation? Do you know
> > what other
> > > ORBs do?
> >
> > There can be no argument about this. The Any continues to own the memory

Maybe not now, but it certainly was arguable until this latest revision.

> > for the string. From section 23.16.3 of the C++ mapping (latest version is
> > http://www.omg.org/pub/docs/ptc/99-03-04.pdf):
> >
> > 	If the extraction is successful, the caller's pointer will point
> > 	to storage managed by the any and operator>>= will return TRUE.
> > 	The caller must not try to delete or otherwise release this storage.
> >
> > OmniORB is wrong, I'm afraid, and the mapping has been this way for years.

This is not the case. The new document is dated May '99, and previous
versions of the spec were certainly not clear. The mapping is defined
by the specification.

> > Other ORBs (Visi, Orbix, ORBacus, ORB Plus) implement this correctly.
> >
> > 							Cheers,
> >
> > 								Michi.
> > --
> > Michi Henning               +61 7 3236 1633
> > Triodia Technologies        +61 4 1118 2700 (mobile)
> > PO Box 372                  +61 7 3211 0047 (fax)
> > Annerley 4103               michi@triodia.com
> > AUSTRALIA
> http://www.triodia.com/staff/michi-henning.html