[omniORB] Possible bug in omniORB 2.7.1

[Poilpret Jean Francois]

Sai-Lai,

I applied your patch, and everything works as expected now.
Thanks a lot for your prompt answer.

Jean-Frangois Poilprjt

-----Original Message-----
From: Sai-Lai Lo <S.Lo@uk.research.att.com>
To: Poilpret Jean Francois <jfpoilpret@hn.vnn.vn>
Cc: omniorb-list@uk.research.att.com <omniorb-list@uk.research.att.com>
Date: lundi 17 avril 2000 17:34
Subject: Re: [omniORB] Possible bug in omniORB 2.7.1


>Poilpret,
>
>Your example seems to me is a legitimate use of the mapping and has not
>been covered by omniORB2.
>
>The following is a patch to omni2.7.1 (I believe it should also apply with
>no problem to omni2.8.0:
>
>Please note that there should be a proper check in the _d() set function to
>see if the argument is valid. This is only partially implemented in the
>code below. What it should also check is that the value is none of those of
>the labelled union branches. For your purpose I hope it is sufficent:
>
>diff -r -c omni2.7.1/src/tool/omniidl2/omniORB2_be/o2be_union.cc
omni2.7.1-new/s
>rc/tool/omniidl2/omniORB2_be/o2be_union.cc
>*** omni2.7.1/src/tool/omniidl2/omniORB2_be/o2be_union.cc       Mon Apr 17
11:18
>:46 2000
>--- omni2.7.1-new/src/tool/omniidl2/omniORB2_be/o2be_union.cc   Mon Apr 17
11:18
>:20 2000
>***************
>*** 547,553 ****
>            << " _d () const { return pd__d;}\n";
>    IND(s); s << "void _d("
>            <<
o2be_name::narrow_and_produce_unambiguous_name(disc_type(),this)
>!           << " _value) {}\n\n";
>
>    if (nodefault() && !no_missing_disc_value())
>      {
>--- 547,553 ----
>            << " _d () const { return pd__d;}\n";
>    IND(s); s << "void _d("
>            <<
o2be_name::narrow_and_produce_unambiguous_name(disc_type(),this)
>!           << " _value) { pd__d = (pd__default ? _value : pd__d); }\n\n";
>
>    if (nodefault() && !no_missing_disc_value())
>      {
>
>
>Sai-Lai
>
>
>
>
>>>>>> Poilpret Jean Francois writes:
>
>> 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...) ?
>
>
>--
>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