ORBit2 issues (was Re: ORBit 0.5.15 any problem?)

[Huw Rogers <count0 building2 co jp>]

It's far more likely that the problem is with ORBit2, not with ORBit
stable. Based on reading this list, there seem to be issues with
typecode marshalling / alignment and interoperability with ORBit2. I
recommend testing passing IDL structs and unions of the form

struct testStruct {
char pad1;
any a;
char pad2;
any b;
};

typedef sequence<testStruct> testStructSeq;

union testUnion switch(boolean) {
case FALSE: testStruct tStruct;
case TRUE: sequence<testStruct> tStructSeq;
};

typedef sequence<testUnion> testUnionSeq;

Then passing these types back/forwards between ORBs in a test program
with various kinds of data in the anys (shorts, longs, long longs, etc.).

I would use omniORB and ACE/TAO to test against, since these are well
known to behave correctly.

Marshalling/demarshalling long long and unsigned long long members of
unions seems on it's face to be broken in ORBit2 (it appears to attempt
to force them into a 32bit ulong).

	-Huw

> I haven't tracked this down completely but it appears right now that
> ORBit0.5.15 may have a problem with the "any" marshalling.   I have a
> struct with a double in it and a short that the short gets corrupted
> somehow.  I don't know yet if this is a problem in the IDL generation or in
> the ORB Any handling.  Was there a fix that ORBit2 has that didn't get
> migrated to ORBit?   ORBit2 ran fine with the same IDL.
> 
> Also, with ORBit this problem seems to show up in the NameServer (I think
> it uses Any's but I haven't had a chance to look closely)...  E.g.  Create
> a naming context, then list the contents of the context.

-- 
Huw Rogers <rogers@building2.co.jp>