The following bugs in omniORB 3.0.1 have been fixed. You can
get the fixes in three ways:
|
| Summary: | Clash with name _T
(bug number 14)
|
| Date: | Mon Sep 25 11:52:16 BST 2000 |
| Fixed by: | dpg1 |
| 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 |
| Fixed by: | sll |
| Reported by: | Sai-Lai Lo |
| Link for this bug: | http://www.uk.research.att.com/omniORB/archives/2000-08/0241.html |
| 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 |
| Fixed by: | djs |
| Reported by: | NODA Itsuki |
| Link for this bug: | http://www.uk.research.att.com/omniORB/archives/2000-09/0090.html |
| 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 |
| Fixed by: | dpg1 |
| 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 |
| Fixed by: | djs |
| Reported by: | Chris Newbold |
| Link for this bug: | http://www.uk.research.att.com/omniORB/archives/2000-09/0054.html |
| 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 |
| Fixed by: | dpg1 |
| 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 |
| Fixed by: | dpg1 |
| 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 |
| Fixed by: | dpg1 |
| 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 |
| Fixed by: | dpg1 |
| 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 |
| Fixed by: | dpg1 |
| 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 |
| Fixed by: | djs |
| 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 |
| Fixed by: | sll |
| Reported by: | Chris Newbold |
| Link for this bug: | http://www.uk.research.att.com/omniORB/archives/2000-08/0066.html |
| 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 |
| Fixed by: | dpg1 |
| Reported by: | Mark Borges |
| Link for this bug: | http://www.uk.research.att.com/omniORB/archives/2000-08/0170.html |
| Description: | Make rules for the omniDynamic shared library were missing, so
the new libCOS failed to link. |
|
| Summary: | Typo in omniidl.idltype.Declared.name()
(bug number 1)
|
| Date: | Mon Aug 21 10:11:51 BST 2000 |
| Fixed by: | dpg1 |
| 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.
|
|
