[omniORB] CORBA_Long typedefs

[Daniel Krügler]

 Am Mo., 4. Feb. 2019 um 17:10 Uhr schrieb Igor Ingultsov via
omniORB-list <omniorb-list at omniorb-support.com>:
>
> Hi All,
>
> we are using omniORB 4.2 and we are interested in making our application
> cross-platform.
>
> As you know, Windows and Linux have different 64 bit data models: LLP64
> (sizeof(long) == 4) and LP64 (sizeof(long) == 8) accordingly.
> OmniORB still defines CORBA_Long as 32 bit integer type on every
> platform which is good.
>
> Our problem is, that the corresponding typedefs are using different
> integer types:
> on windows:
> typedef long CORBA_Long;
> typedef unsigned long CORBA_ULong;
>
> on linux:
> typedef int CORBA_Long;
> typedef unsigned int CORBA_ULong;
>
> which are incompatible in general. This causes following problem:
> void f(int& out) { out = 42; }
> void g(long& out) { out = 42; }
> void h(int32_t& out) { out = 42; }
> ...
> CORBA_Long cl {};
> f(cl); // error: on windows, due to typedef long CORBA_Long;
> g(cl); // error: on linux, due to typedef int CORBA_Long;
> h(cl); // error: on windows, again due to typedef long CORBA_Long;
>
> We would prefer to use everywhere fixed width integer types anyway
> instead of long (aka int32_t/uint32_t), but we'll still have problem
> with windows, because of 'long'.
> We are also aware of the fact, that it's kinda ugly to do such calls.
>
> Our question is: Would it make sense to change those typedefs in
> CORBA_basetypes.h to use fixed width integer types (if available on the
> platform)? (I assume, it would not have any consequences)
> Would it be useful to others if you also introduce the change into
> upstream, which could look like something like this:
>
> --- a/include/omniORB4/CORBA_basetypes.h    Mon Feb 04 10:15:37 2019 +0100
> +++ b/include/omniORB4/CORBA_basetypes.h    Mon Feb 04 15:43:29 2019 +0100
> @@ -44,6 +44,15 @@
>
>   typedef unsigned short            _CORBA_UShort;
>
> +#if HAVE_STD && (__cplusplus >= 201103L || (defined(_MSC_VER) &&
> _MSC_VER >= 1900))
> +#include <cstdint>
> +#  ifndef OMNI_LONG_IS_INT
> +#    define OMNI_LONG_IS_INT
> +#  endif
> +typedef int32_t                   _CORBA_Long;
> +typedef uint32_t                  _CORBA_ULong;
> +#else
> +
>   #if SIZEOF_LONG == 4
>   typedef long                      _CORBA_Long;
>
> @@ -61,6 +70,8 @@
>   # error "Can't map Long (32 bits) to a native type."
>   #endif
>
> +#endif
> +
>   typedef _CORBA_WCHAR_DECL         _CORBA_WChar;
>
>   #ifdef HAS_LongLong
>
> Thank you in advance.

I'm strongly opposing to this change, for the following reasons:

1) In C++98/03 CORBA language mapping you have no chance anyway to
rely on specific overloading. The specification is intentionally fuzzy
in that regard and once you need to support more than one CORBA vendor
(And our company does need to do that), then you will observe that
such variations are reality.
2) The C++ stdint types don't give you guarantees to which the type
aliases intNN_t will actually refer to, so there is no guarantee that
these types are the same on Windows and Linux compilers. You can still
end up in ambiguities when combining int, long, and intNN_t types in
overloaded functions.
3) I'm pretty sure that your suggested change will break existing code
somewhere in the wild.

If you have the luxury to switch to a CORBA vendor that provides
support for the C++11 language mapping, you have more guarantees about
the binding types (In particular, you have the guarantee that all
primitive type mappings have different types - this guarantee does not
hold for the C++98/03 for some of the primitive types).

- Daniel