[omniORB] Possible bug in omniORB 2.7.1

[Sai-Lai Lo]

Guy,

Bug report should come to this list. Any response will also come to the
list. Hence the searchable archive of this list is a good source to check
if bugs have been fixed or reported.

I believe omniORB's behaviour is compliant.

It is true that the proper way to select the branch and hence set the
discriminant is to do something like:

> B dummy;
> data.anb(dummy)

This is so because the "modifying" function is called.

On the other hand, in your code:

> data.anb().bvalue = 5

The function anb() is a "referent" function as described in the paragraph
you quoted. It follows that the discriminator will not be changed as a
side-effect of calling an(). In fact, this call is not legal if the
discriminator value is not TRUE.

It is true that _d(type) is a no-op at the moment. This is so because
the IDL frontend we have been using cannot handle union branch with more
than one label. As _d(type) is only meant to change the discriminator to a
different label value *of the same branch*, there is no point in doing more
that a no-op if the IDL frontend already rejects any union branch with
multiple labels.

The new compiler frontend, which has already been in use in omniORBpy,
fully support the IDL syntax of CORBA 2.3, including the multiple labels
branch. A backend for omniORB2 is currently being written to use the new
frontend.


Regards,

Sai-Lai

>>>>> Guy Evans writes:

> In omniORB 2.7.1 the discriminant setting function for a union _d(type)
> is a no-op!  This usually doesn't matter, since it gets implicitly set
> according to the usage of the union. However I got stung in the
> following example :-

> struct A {
>  string avalue;
> };

> struct B {
>   long bvalue;
> };

> union Data switch (boolean) {
>  case FALSE: A ana;
>  case TRUE: B anb;
> };

> I had code which did :-

> data.anb().bvalue = 5

> (under the assumption that the discriminant would be implicitly set).
> On examining the union, however, I noticed the discriminant was equal to
> FALSE.  I therefore tried :-

> data._d(TRUE);

> but since this is a no-op it doesn't work.

> So with ominiORB the only one to set the discriminant in this case is to
> do :-

> B dummy;
> data.anb(dummy)

> I was kind of surprised that "data.anb().bvalue = 5" did not implicitly
> set the discriminant.   Looking at the latest CORBA spec though this
> appears to be compliant (the CORBA spec states that the implicit setting
> of the discriminant only occurs for the "modifying" functions (the
> functions which explicit set the value) as opposed to "referents" (the
> functions which obtaining a read/write reference to the value).

> Is _d(TYPE) being a no-op fixed in the latest version?  Is there an
> official mechanism for reporting bugs?


-- 
Sai-Lai Lo                                   S.Lo@uk.research.att.com
AT&T Laboratories Cambridge           WWW:   http://www.uk.research.att.com 
24a Trumpington Street                Tel:   +44 1223 343000
Cambridge CB2 1QA                     Fax:   +44 1223 313542
ENGLAND