[omniORB] Declaration of _CORBA_ULONGLONG_DECL on gcc (32 and 64
- bit)
Duncan Grisby
duncan at grisby.org
Thu Jul 2 10:28:03 BST 2009
On Monday 8 June, Matej Kenda wrote:
> I have noticed an inconsistency between the declarations of 64-bit
> integers in CORBA_sysdep_trad.h and CORBA_sysdep_auto.h when compiling
> with gcc.
[...]
> When compiling with gcc for 32-bit target, CORBA::UlongLong is defined
> as "unsigned long long" in both cases, however when compiling for
> 64-bit target, CORBA::UlongLong is defined as "unsigned long long" or
> "unsigned long" respectively.
That's a historical artifact -- the trad version predates GCC on 64 bit
platforms. I don't think anyone really uses the trad build on
non-Windows platforms any more do they?
> The consequence of this inconsistency is that source code that
> compiles well for 32-bit target, doesn't compile for 64-bit target,
> when using _auto.h.
>
> Example:
>
> CORBA::Any_var any_value;
> any_value = server->GetParameterByName("parameter.name");
> unsigned long long value;
> any_value ==> value;
>
> This code fails to compile for 64-bit target:
You're not meant to mix non-CORBA types with CORBA types without being
explicit about it, so that's not expected to work in the C++ mapping.
There are too many integer types for all of them to map to CORBA types.
The same issue arises on 32 bit platforms about whether CORBA::Long is
int or long, for example.
I don't think it's appropriate to change the autoconf build to use long
long for 64 bit types on 64 bit platforms. It definitely can't be done
on the 4.1.x branch because it would break binary compatibility.
Of course, nothing stops you from using your own patched version that
does use long long.
Cheers,
Duncan.
--
-- Duncan Grisby --
-- duncan at grisby.org --
-- http://www.grisby.org --
More information about the omniORB-list
mailing list