[omniORB] Possible bug in omniORB 2.7.1

[Poilpret Jean Francois]

Hi all omniORB'ers,

First of all, I apologize for using an old mail of this list to describe my
problem, but this was the one I found closest to my problem.

At this time, I use omniORB 2.8 on Linux.

My problem is with unions and defaults.
The original mail complained about the "no-op" _d() member function in all
generated-classes mapped to IDL unions.
The answer of Sai-Lai indicated that "since omniidl does not support multiple
cases labels, there is no need for a working _d() method".
Unfortunately, this is not true.

This would be tru for the followin IDL snippet:

enum XXX {one, two, three};

union YYY switch(XXX) {
    case one:
    case two:
    string    myString;

    case three:
    int        myInt;
};

since omniidl refuses to compile it (this is a long-known problem, for which
the workaround is "use omniORB 3 instead"). I don't complain about this
point.

But there are other cases, where omniidl actually compiles IDL snippet (see
after), and where the _d() member function SHOULD work:

enum XXX {one, two, three};

union YYY switch(XXX) {
    case three:
    int        myInt;
};

Here, omniidl does not complain, but in this case, I may want to do something
like this in my C++ code (actually, I DO NEED to do something like this ;-)):

YYY    yyy;
yyy._default();
yyy._d(two);

If, after this, I try to read the discriminator value:

std::cout << yyy._d() << std::endl;

the walue is "one", not "two"; this is because the "_default()" method
initialized it to be the first enumerated value (of enum XXX) which does not
appear in any case label.

But there are many cases where one would like to use the discriminator value
to hold meaningful information (this is my case), in particular for the
implicit default case, for which there is no other available information than
the discriminator value itself.

So what can I do here (please don't tell me: "use omniORB 3.0", I'm not ready
yet to upgrade (I think I will in one or two months, but for now, I really
have no time to do so))?

Is it possible to path the omniidl compiler to add the right code (only one
line in fact, regarding my sole problem, since I still did not take care about
any side-effect problems...) ?

Best regards,

    Jean-Francois Poilprjt

-----Original Message-----
From: Sai-Lai Lo <S.Lo@uk.research.att.com>
To: Guy Evans <gevans@tumbleweed.com>
Cc: omniorb-list@uk.research.att.com <omniorb-list@uk.research.att.com>
Date: vendredi 19 novembre 1999 21:34
Subject: Re: [omniORB] Possible bug in omniORB 2.7.1


>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