[omniORB] Possible bug in omniORB 2.7.1
Guy Evans
gevans@tumbleweed.com
Fri, 19 Nov 1999 12:12:07 +0000
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