[omniORB] Recursive structures in anys

[Michael]

Hello,

I stumbled over an issue regarding recursive structures in IDLs. Basically it is the same
issue posted by Renzo Tomaselli backin 2005 (see below), but I couldn't find any
indication that this has ever been fixed.

In contrast to Renzo I'm not building a DynAny but I'm just sending the recursive struct
inside of an any (the process dies on signal 6 somewhere inside of omniorb).

pseudoIDL:
struct Message
{
  long id;
  any payload;
};

struct Entry;
typedef sequence<Entry> EntrySeq;
struct Entry
{
  string name;
  EntrySeq entries;
};

pseudocode:
Entry e;
e.name="test";
e.entries.length(1);
e.entries[0].name="test2";

Message m;
m.id = 1;
m.payload <<= e;

factory->doremotecall(m);
==>
pure virtual method called
terminate called without an active exception
Abort trap: 6 (core dumped)

The anonymous construct works ok:
struct Entry
{
  string name;
  sequence<Entry> entries;
};

but omniidl gives a warning:
"Warning: Anonymous sequences for recursive structures are deprecated. Use a forward
declaration instead".

regards
michael

-- Post of Renzo Thu Apr 7 21:00:20 BST 2005

Hi,
    it's me again. Indeed, the alternative construction:

struct JobNode {
   sequence<JobNode, 2>next;
};
typedef sequence<JobNode, 2> JobNodeList;

works fine, since the failing alias is moved outside. Btw, this is the
common form of all OMG recursion examples.
However, omniidl complains saying "Warning: Anonymous sequences for
recursive structures are deprecated. Use a forward declaration instead".
Just a warning, but exactly what is not actually working in dynamic
procedures.

Renzo

Renzo Tomaselli wrote:

> Hi all,
>    I have some problems while building a recursive typecode
> dynamically, while everythings works file from standard idl (e.g.
> static) usage.
> Let's consider the canonical binary tree example (pasting from my idl):
>
> typedef sequence<JobNode, 2> JobNodeList;
> struct JobNode {
>    JobNodeList next;
> };
>
> In a dynamic building procedure, we would have:
>
> CORBA::TypeCode_var tcNode =
> orb->create_recursive_tc("IDL:/JobNode:1.0");
> CORBA::TypeCode_var tcSeq = orb->create_sequence_tc(2, tcNode);
> CORBA::TypeCode_var tcAlias =
> orb->create_alias_tc("IDL:/JobNodeList:1.0", "JobNodeList", tcSeq);
> ...
> the last statement throws an exception from method NP_resolved(),
> since it tries to match JobNodeList vs. Node, failing of course.
> Indeed JobNode would be resolved one step out. I guess a nested
> definition would work as a workaround (I'll try it later), however I
> feel this behavior fighting against the correct behavior while derived
> from static idl.
> Any suggestion ? Thanks,
>
> Renzo Tomaselli
>
>