[omniORB] Tripping over omniORB non-ANSI code using Sun native v5.0 compile r

[Smith, Norman]

I am trying to build omniORB source using native Sun Workshop v5.0 under
Solaris 2.5 and 2.7 without success. The following error is produced when
attempting to compile and build omniNames:
 
-------------------------------------------------------
CC -c -O2 -fsimple  -I. -D__OMNIORB2__ -I../../../stub -DUsePthread
-D_REENTRANT -mt -DDEFAULT_LOGDIR='"\"/var/omninames\""' -I.
-I../../../include -D__sparc__ -D__sunos__ -D__OSVERSION__=5 -o omniNames.o
omniNames.cc
"./NamingContext_i.h", line 39: Error: ")" expected instead of "boa".
"./NamingContext_i.h", line 79: Error: Type name expected instead of "log".
"./NamingContext_i.h", line 79: Error: No storage class or type for this
declaration.
"./NamingContext_i.h", line 79: Error: "," expected instead of "*".
"./NamingContext_i.h", line 86: Error: Use ";" to terminate declarations.
"omniNames.cc", line 144: Error: log is not defined.
"omniNames.cc", line 144: Error: Cannot use char* to initialize int.
"omniNames.cc", line 171: Error: Variable l is not a structure.
"omniNames.cc", line 189: Error: Variable l is not a structure.
9 Error(s) detected.
make: *** [omniNames.o] Error 9
-----------------------------------------------------
 
The problem is produced by the fact that the iostream.h header file has a
global method called "log", which collides with the classname called "log"
in the omniNames code base. Hence any subsequent use of the name "log" as a
class definition produces errors.
 
I would like to request a patch to the source code to resolve this issue. A
couple of alternatives would be to rename the omniNames "log" class (which
seems to be localized to the omniNames source code) or take advantage of
namespace scoping to eliminate the naming conflict.
 
Here is some background on the steps we took to arrive at the conclusion
that the omniORB source needs fixing:
 
We distilled the code down to the following snippet and sent it to Sun as a
bug report, since we believed this to be a legal C++ construct. (Also, GNU
2.8.1 on Sun as well as native HP-UX and Digital Unix compilers didn't have
a problem with it.)
 
#include <iostream.h>
class log{};
int main()
{
  log aLog;
  return(0);
}
 
This snippet produces the following error, mimicking the problem in
omniNames, since the function "log" is defined in the same namespace in
iostream.h:
 
CC -o suntest.sol suntest.cpp
"suntest.cpp", line 5: Error: log is not defined.
1 Error(s) detected.

Sun convinced us that this code construct is indeed not ANSI compliant, and
that the Sun v5.0 compiler has been made strictly compliant in this area.
Here is the excerpt from the ISO standard that covers this problem:
 
----------
ISO 14882 states:
 
3.3.7 Name Hiding
2.  A class name or enumeration name can be hidden by the name of an object,
function, or enumerator declared in the same scope.  If a class or
enumeration name and an object, function, or enumerator are declared in the
same scope (in any order) with the same name, the class or enumeration name
is hidden wherever the object, function, or enumerator name is visible.
----------
 
 In summary, we are getting past this problem right now by using GNU, but
have a directive to use the native Sun compiler on our project. Sun suggests
that we use the -compat=4 switch to use the relaxed ANSI compliance in v4.2
of the compiler, but that is also not acceptable.
 
Can you help?