[omniORB] Two bugs in omniidl

[Will Denissen]

Dear Duncan,

The following small idl files reveals two bugs in omniidl 4.1.3 cxx
backend

------------------- bug.idl ---------------------------------
module tst_mod {
const double C1 = 0.00000001;

typedef long T;

struct S_tag {
::tst_mod::T T;
::tst_mod::T S;
};
};
------------------- end of bug.idl ---------------------------



It will generate



------------------- bugSK.cc ---------------------------------

// This file is generated by omniidl (C++ backend)- omniORB_4_1. Do not
edit.

#include "bug.hh"
#include <omniORB4/IOP_S.h>
#include <omniORB4/IOP_C.h>
#include <omniORB4/callDescriptor.h>
#include <omniORB4/callHandle.h>
#include <omniORB4/objTracker.h>


OMNI_USING_NAMESPACE(omni)

static const char* _0RL_library_version = omniORB_4_1;



#if defined(HAS_Cplusplus_Namespace) && defined(_MSC_VER)
// MSVC++ does not give the constant external linkage othewise.
namespace tst_mod {
extern const ::CORBA::Double C1 = 1e-08.0;
}
#else
const ::CORBA::Double tst_mod::C1 = 1e-08.0;
#endif

void
tst_mod::S_tag::operator>>= (cdrStream &_n) const
{
T >>= _n;
S >>= _n;

}

void
tst_mod::S_tag::operator<<= (cdrStream &_n)
{
(tst_mod::T&)T <<= _n;
(T&)S <<= _n;

}

------------------- end of bugSK.cc --------------------------



BUG:

1) For the special constant C1 it will print the wrong value in C++.

2) For the second field of the structure the type is not fully
qualified

and therefore it is interpreted as being the 1st field of the
structure by the C++ compiler





Is there an easy fix for this?



Will.





W(ill).J.A. Denissen Ph.D

Principal Software Architect



ASML Netherlands B.V.

Building 7, De Run 6665,

5504 DT Veldhoven,

The Netherlands



Phone: [phone]

Email: ***@asml.com

Web: www.asml.com
<file:///C:/Documents%20and%20Settings/wdenisse/Application%20Data/Micro
soft/Signatures/www.asml.com>

[Duncan Grisby]

The following small idl files reveals two bugs in omniidl 4.1.3 cxx backend

Thanks for the bug report. I've fixed both. For the double constant bug
your proposed fix works. For the struct scope issue, the problem is
actually that the type lookup was failing to enter the struct scope so
it didn't notice the clash. Properly entering the scope means the type
is properly fully qualified in case of clashes.

Cheers,

Duncan.