[omniORB] Problem with any.to_any in omniORBpy and DynAny in libomniDynamic

[Michael]

Hi Duncan,

thanks for your effort.
I've got two issues with the to_any code.

1. In the current implementation there is no way to pass an any 
containing TC_null as part of a struct/sequence/union (even if it's 
stated explicitely). In our scenario we actually need the possibility to 
send "empty" anys which would make using to_any impossible.

2. The Corba Standard (corba2.6_01-12-01.pdf), section
"4.11.3 Creating TypeCodes" (page 4-59 at the bottom), states:

....
"Operations that take content or member types as arguments shall
check that they are legitimate (i.e., that they don't have kinds 
tk_null, tk_void or tk_exception). If not, they shall raise the 
BAD_TYPECODE exception with standard minor code 2. Operations that take 
members shall check that the member"
....
(also available here: 
http://www.cs.uwaterloo.ca/~mnojoumi/ThesisFiles/FinalSpec/CORBA/4.11.3.html)

So I think that besides from being strange this actually violates the 
standard (that makes also sense from an IR/IDL perspective, because 
there is no way to create such constructs through an IDL definition).

What do you think?

cheers
michael


Duncan Grisby wrote:
> On Tuesday 19 August, Michael wrote:
> 
> [...]
>> I could track down the problem to the following case in python:
>> serializer.anyToXml(any.to_any({'a':None}))
>>
>> After inspecting what's going on, I figured that to_any does create
>> sequences and structures containing members of type TC_null (which
>> IMHO should not happen, instead they should put in an any "containing"
>> TC_null).
> 
> I'm not sure it's so wrong to have members of type TC_null. It's a bit
> odd, but I don't think there's anything that makes it explicitly
> illegal. I have Python code that makes use of sequences of nulls. I'm
> therefore tempted to leave any.to_any as it is...
> 
> [...]
>> Now for the second issue: Why does the server side crash? (It only
>> crashes for structs, so I will limit my analysis on those):
> 
> That, however, is definitely a bug. There were two related problems.
> First, it didn't support structs / sequences of nulls (which I think it
> should -- it already supported void). Second, when it threw the
> exception to complain about the typecode, it corrupted itself and blew
> up.
> 
> I've fixed both issues in CVS.
> 
> Does that change address your problem?
> 
> Cheers,
> 
> Duncan.
>