omniORB 3.0.1 bugs

The following bugs in omniORB 3.0.1 have been fixed. Update from CVS to get the fixes.

Summary: Clash with name _T (bug number 14)
Date: Mon Sep 25 11:52:16 BST 2000
Reported by: All sorts of people
Description: omniORB used _T as a template class name in various places. This causes problems with standard headers on some platforms, which #define _T. All uses of _T have been changed.

Summary: Workaround for the Sun C++ 5.0 or Forte WS 6.0 exception unwinding bug (bug number 13)
Date: Tue Sep 21 15:13:05 BST 2000
Reported by: Sai-Lai Lo
Description: Sun C++ 5.0 or Forte C++ 6.0 generated code will segv occasionally when concurrent threads throw an exception. The stack trace points to a problem in the exception unwinding. The workaround seems to be to install explicitly an uncaught exception handler.

Summary: C++ backend reversed order of includes in .hh file (bug number 12)
Date: Tue Sep 19 14:50:05 BST 2000
Reported by: NODA Itsuki
Description: If an IDL source file #included <a.idl> and <b.idl> then the resulting header would #include <b.hh> before <a.hh>.

Summary: Bug when assigning a String_var to itself (bug number 11)
Date: Tue Sep 19 10:08:31 BST 2000
Reported by: Stefan Engelhardt
Description: Assigning a String_var to itself would incorrectly delete the string contents.

Summary: omniidl/C++ bug with unions with implicit default members (bug number 10)
Date: Wed Sep 13 10:09:43 BST 2000
Reported by: Chris Newbold
Description: The generated _d(...) method was incomplete, preventing the discriminant from being changed within the set of legal default values after calling _default() on a union with an implicit default member.

Summary: omniidl produces no useful output on Windows 98 (bug number 9)
Date: Mon Sep 11 15:12:38 BST 2000
Reported by: Guangyu Gu, Mark Pumar, others
Description: On some Windows 98 machines, but not others, the C pre-processor output is echoed to the screen, rather than forming the input to omniidl. omniidl therefore fails to generate any code. This fix adds a -T option to omniidl, which uses a temporary file rather than a pipe between the pre-processor and omniidl. It is reported that this works on affected Win98 machines.

Summary: Support for Python 1.6 and 2.0b1 (bug number 8)
Date: Wed Sep 6 12:13:30 BST 2000
Description: omniidl was hard-coded to require Python 1.5.2, just in case later versions were incompatible. 1.6 and 2.0b1 are compatible, so they are now supported.

Summary: #includes of iostream.h left in omniORB headers (bug number 7)
Date: Mon Sep 4 10:02:41 BST 2000
Reported by: Paul Nader
Description: Several files had #include<iostream.h> left behind from debugging. This causes problems for code which does #include <iostream> without the .h.

Summary: BOA constructor with object key broken (bug number 6)
Date: Wed Aug 30 10:43:34 BST 2000
Reported by: Paul Nader
Description: The fix to bug 8 in omniORB 3.0.0 did not actually work.

Summary: omniidl loses all but the first comment with -K (bug number 5)
Date: Fri Aug 25 14:25:20 BST 2000
Reported by: Richard Gruet
Description: On some platforms, omniidl -K would lose all but the first comment attached to a node. The code used a construct whose evaluation order is undefined in C++, so it worked with some compilers, but not others.

Summary: MSVC5/6 marshalling multidimensional arrays of basic types (bug number 4)
Date: Wed Aug 23 16:44:36 BST 2000
Reported by: dme
Description: MSVC5/6 fail to resolve the correct operator[] when marshalling a multidimensional array of basic types, only in the return case (not when using an out type)

Summary: "Unexpected" exception at initialization (bug number 3)
Date: Tue Aug 22 15:48:11 BST 2000
Reported by: Chris Newbold
Description: When the port specified via -ORBpoa_iiop_port happens to be in use, an internal omniORB exception is raised by resolve_initial_reference(). Now a system exception CORBA::INITIALIZE is raised instead.

Summary: Missing make rules for GCC on Solaris (bug number 2)
Date: Tue Aug 22 10:59:21 BST 2000
Reported by: Mark Borges
Description: Make rules for the omniDynamic shared library were missing, so the new libCOS failed to link.

Summary: Typo in (bug number 1)
Date: Mon Aug 21 10:11:51 BST 2000
Reported by: Richard Gruet
Description: The name() function of idltype.Declared accidentally returned a list containing a single string rather than just the string itself.