[omniORB] Possible bug in omniORB 2.7.1

[David Riddoch]

Guy,

Unfortunately your code is wrong.  It is not legal to use the discriminant
modifier to select a union member as you are doing (sec 1.12 of the c++
spec). It can only be used to change to another label for the same
(already selected) member.  Since omniORB does not yet support multiple
labels per member, there can never be a useful use for it -- and hence it
is a no-op.

The only way to select a member is as you have done near the bottom of
your message -- and that should be the case for all ORBs.

Cheers,
David


On Fri, 19 Nov 1999, Guy Evans wrote:

> Hi,
> 
> 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?
> 
> Cheers
> Guy
> 
> 
> 
> 
>