[omniORB] CORBA.BAD_PARAM(omniORB.BAD_PARAM_ValueFactoryFailure, CORBA.COMPLETED_NO) Failure

[Duncan Grisby]

On Mon, 2021-08-02 at 08:20 +0000, Fackler Maximilian via omniORB-list
wrote:

> module Example {
>  
>     valuetype ParamType unsigned short;
>     valuetype InnerULong unsigned long;
>  
>     struct MyStruct {
>         InnerULong member;
>     };
>  
>     interface Echo {
>         void execute(in ParamType a, in Example::MyStruct b);
>     };
> };
> 
> The Error occurs when the execute function of the Echo interface is
> called from python to a c++ servant.
> I made the following observations:
> ·        Error occurs only if the value of “ParamType a” is equal to
> the “InnerULong member” of MyStruct -> execute(0, MyStruct(member=0))

This is a bug in omniORBpy that causes it to send incorrect data. That
causes C++ omniORB to (correctly) report a failure.

The problem is that both the zero integers in Python are the same zero
object. The sending code in omniORB therefore incorrectly thinks that
the second zero valuebox (of type unsigned long) is the same valuebox
as the first one (of type unsigned short), and sends it as an
indirection to the first one. In IDL they have different types, so it
is not permitted for them to be the same object.

> Is the usage of valuetype for InnerULong “not a good practice” and a
> typedef preferable?

Why are you using valuetype here?  It makes everything substantially
more complex and less efficient.

> Or should this example work without any problems?

It should work without problems, but I would still recommend that you
don't use valuetype for boxing simple integer types. valuetypes are
good if you need to transmit complex recursive types like trees or
graphs, but for something as trivial as an integer, it is an
unnecessary complication.

Duncan.

-- 
Duncan Grisby <duncan at grisby.org>