[omniORB] warning-free compile of omniORB code in 32- and 64-bit environments

[Raschick, Hartmut]

Hello Duncan,
we recently ported a project (which uses omniORB) to 64-bit with the goal of retaining 32-bit compatibility (i.e. also being able to compile - esp. using gcc - the code warning-free both in 64- and 32-bit environments). As CORBA defines a CORBA::(U)Long to be 32-bit guaranteed, using that was our primary objective. When sanity checking with printf-alike functions (i.e. ones with format-strings) we saw many compiler warnings of the type "format identifier says long, but parameter is int" when compiling 64-bit or "format says int, but parameter is of type long" when compiling 32-bit and not specifying "%l" in the format string. One way or other there were such clashes.
To our understanding this is due to the way how omniORB defines the Long/ULong base types: consider the following lines in "include/omniORB4/CORBA_basetypes.h":

<snip>
#if SIZEOF_LONG == 4
typedef long                      _CORBA_Long;

typedef unsigned long             _CORBA_ULong;

#elif SIZEOF_INT == 4
#  ifndef OMNI_LONG_IS_INT
#    define OMNI_LONG_IS_INT
#  endif

typedef int                       _CORBA_Long;

typedef unsigned int              _CORBA_ULong;
#else
# error "Can't map Long (32 bits) to a native type."
#endif 
<snap>

It would seem that reversing above checks like so:

<snip>
#if  SIZEOF_INT == 4
#  ifndef OMNI_LONG_IS_INT
#    define OMNI_LONG_IS_INT
#  endif

typedef int                       _CORBA_Long;

typedef unsigned int              _CORBA_ULong;
#elif SIZEOF_LONG == 4
typedef long                      _CORBA_Long;

typedef unsigned long             _CORBA_ULong;

#else
# error "Can't map Long (32 bits) to a native type."
#endif
<snap>

solves this "problem".
Unless there is - say - something in the OMG specs requiring that under 32-bit a CORBA::Long must be a long (because this is how it's called, right) or there are other obstacles, it might perhaps be an option to use the latter define sequence to avoid abovementioned compiler warnings without resorting to explicit casts every time.

cheers
hardy

Hartmut Raschick
Network Management Solutions
-----------------------------------
KEYMILE GmbH
Wohlenbergstr. 3
D-30175 Hannover, Germany

Phone: +49 (0)511 6747-564
Fax:   +49 (0)511 6747-777
mailto:Hartmut.Raschick at keymile.com
http://www.keymile.com

<< KEYMILE: A Specialist as a Partner >>

Geschäftsführer/Managing Directors: Björn Claaßen, Michael Breyer, Axel Föry - Rechtsform der Gesellschaft/Legal structure: GmbH, Sitz/Registered office: Hannover HRB 61069, Amtsgericht/Local court Hannover, USt-Id. Nr./VAT-Reg.-No.: DE 812282795, WEEE-Reg.-No.: DE 59336750