[omniORB] generated types copy constructor problem

[Michael Teske]

Am 13.04.15 um 16:00 schrieb Johnny Willemsen:
> Hi,
> 
>>> I don't know the details of the omniORB implementation, but the formal
>>> IDL to C++ language mapping says the following:
>>>
>>> The default union constructor performs no application-visible
>>> initialization of the union. It does not initialize the discriminator,
>>> nor does it initialize any union members to a state useful to an
>>> application. (The implementation of the default constructor can do
>>> whatever type of initialization it wants to, but such initialization is
>>> implementation-dependent. No compliant application can count on a union
>>> ever being properly initialized by the default constructor alone.)
>>
>> Exactly, and that's why omniORB doesn't default-construct unions or
>> allow non-initialised ones to be copied. I'm afraid that application
>> code that attempts to copy a non-initialised union is invalid.
> 
> Yes, also TAO doesn't guarantee that it works to copy a non-initialised
> union.

So I guess I have to accept that. Unfortunately I have to port lots of
code from orbacus, which didn't crash when inserting corba union types
into map containers (where the application has no control over how such
functions are implemented).
Another bad habit I found (probably illegal, too) is to have a sequence
of these union types set to e.g. length 20, initialize 10 with values
and then increase the length to 21 which will in case of a needed
reallocation lead to a copy of the elements, which may crash between
elements 10 to 19....
Since I don't have the time to check all that code I'll have to patch
our local copy of onmiorb to allow copies of uninitialised unions by
inserting something like
if (!_value._pd__initialised) return;
at the beginning of the copy constructor.
I understand that this will not make it into omniorb, but i guess
template.py would be the right location here?

Greetings,
  Micahel