[omniORB] DynAny and typecode aliases

[Duncan Grisby]

On Tuesday 12 October, Stephen Crawley wrote:

>   CORBA::TypeCode_ptr tc = // ... typecode for "typedef long Int;"
> 
>   CORBA::DynAny_ptr da = orb -> create_dyn_basic_type(tc);
> 
>   cerr << "kind is " << kind_to_string(da -> type() -> kind()) << endl;
> 
> is printing "kind is long", not "kind is alias".
> 
> The problem is that CORBA::ORB::create_basic_dyn_any() is stripping
> off the aliasing and creating the DynAnyImpl object with the stripped
> typecode.  This violates the intent of the CORBA 2.2 spec.

I wasn't involved in omniORB's DynAny implementation, but I've just
read the 2.2 spec. It does not specify how the TypeCodes should be
assigned at all, except the paragraph

  "The create_dyn_any operations creates a new DynAny object from an
   any value. A duplicate of the TypeCode associated with the any
   value is assigned to the resulting DynAny object. ..."

No specific behaviour is given for the creation functions which take
TypeCode arguments.

It could be argued, as you do, that the TypeCodes should be duplicated
without change. However, it can also be argued that without a notion
of TypeCode equivalence (which was introduced with 2.3), it is more
useful to strip any aliases (i.e. compact the TypeCodes in 2.3
terminology) so that typecodes of structurally equivalent types
compare equal.

This is something which needs to be clarified in the spec, since it is
not at all obvious to my reading. Unfortunately, the 2.3 spec still
doesn't make it explicit. It seems odd to me that both specs are very
clear about the behaviour when generating a DynAny from an Any, but
not at all clear about generation with a TypeCode. Since issues of
TypeCode equivalence have now been clarified, however, a better
argument can be made for keeping alises in the TypeCodes.


Cheers,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --