[omniORB] Another bug in omniidl 4.1.3 cxx backend --> fixes

[Will Denissen]

Dear Duncan,

The following patches did fix the problem below.

#diff -r org/omniidl_be/cxx/header/defs.py omniidl_be/cxx/header/defs.py
946a947,948

fqname = id.Name(d.scopedName()).fullyQualify()

950c952,953
< name = derivedName)
---

name = derivedName,
fqname = fqname)

956c959,960
< name = derivedName)
---

name = derivedName,
fqname = fqname)

#diff -r org/omniidl_be/cxx/header/template.py
omniidl_be/cxx/header/template.py
875,877c875,877
< static inline @***@_slice* alloc() { return @***@_alloc(); }
< static inline @***@_slice* dup(const @***@_slice* p) { return
@***@_dup(p); }
< static inline void free(@***@_slice* p) { @***@_free(p); }
---
@***@_dup(p); }
Could you please check whether this is a correct patch?
Although it fixes the problem, it is still not clear to me why the C++
compiler is
complaining about ambiguities because the declarations were made in
different namespaces?

c++ -v

Using built-in specs.
Target: sparc-sun-solaris2.8
Configured with: ../sources/gcc-4.1.2/configure --disable-nls
--prefix=/cadappl/gcc/4.1.2/gcc --enable-threads=posix
--disable-target-optspace --enable-languages=c,c++
Thread model: posix
gcc version 4.1.2

Best regard,

Will Denissen.





________________________________

From: omniorb-list-***@omniorb-support.com
[mailto:omniorb-list-***@omniorb-support.com] On Behalf Of Will
Denissen
Sent: Tuesday, November 25, 2008 15:53 PM
To: omniorb-***@omniorb-support.com
Subject: [omniORB] Another bug in omniidl 4.1.3 cxx backend



Dear Duncan,

The following small idl file reveals a bug in omniidl 4.1.3 cxx
backend

------------------- bug2.idl ---------------------------------
module M1 {
struct S {
long T;
};

typedef ::M1::S A[4];
};

module M2 {
typedef ::M1::S A[2];
};
------------------- end of bug2.idl ---------------------------

feeding the generated C++ code to the compiler gives:

bug2.hh: In static member function 'static M2::A_slice*
M2::A_copyHelper::dup(const M2::A_slice*)':
bug2.hh:166: error: call of overloaded 'A_dup(const
M2::A_slice*&)' is ambiguous
bug2.hh:136: note: candidates are: M2::A_slice* M2::A_dup(const
M2::A_slice*)
bug2.hh:84: note: M1::A_slice* M1::A_dup(const
M1::A_slice*)
bug2.hh: In static member function 'static void
M2::A_copyHelper::free(M2::A_slice*)':
bug2.hh:167: error: call of overloaded 'A_free(M2::A_slice*&)'
is ambiguous
bug2.hh:159: note: candidates are: void M2::A_free(M2::A_slice*)
bug2.hh:107: note: void M1::A_free(M1::A_slice*)




Best regards,

Will Denissen

[Duncan Grisby]

Post by Will Denissen
The following patches did fix the problem below.

Please only submit patches in unified or context diff format. The old
diff style is too fragile to safely apply, and is hard to understand.

[...]

Post by Will Denissen
Could you please check whether this is a correct patch? Although it
fixes the problem, it is still not clear to me why the C++ compiler is
complaining about ambiguities because the declarations were made in
different namespaces?

Name clashes between namespaces are a nightmare area in C++ compilers.
There are compilers with mutually incompatible bugs. I am not at all
sure that your suggested fixes are safe to apply, because they may well
trigger bugs in some compilers. Visual C++ is a particular culprit when
it comes to getting it wrong.

This issue looks like a bug in gcc, but I'd have to check in more depth.

Are these issues you're finding in real IDL? In general, any IDL that
triggers these kinds of bugs is asking for trouble and would better be
resolved by making the IDL less ambiguous. The big risk with fixing some
of these obscure namespace issues is that the fixes can completely break
all code for some compilers. See the OMNIORB_BASE_CTOR macro in
CORBA_sysdep.h for an example of the pain of dealing with this.

Cheers,

Duncan.

[Duncan Grisby]

On Tuesday 25 November, Will Denissen wrote:

[...]

Post by Will Denissen
Could you please check whether this is a correct patch?
Although it fixes the problem, it is still not clear to me why the C++
compiler is
complaining about ambiguities because the declarations were made in different
namespaces?

I've now checked in that fix you suggest. with a minor tweak to globally
scope the declarations. We'll find out whether it breaks on some other
C++ compiler...

I think GCC is actually correct to say that the functions are ambiguous,
since the use of a type from namespace M1 introduces M1's functions into
scope.

Cheers,

Duncan.