[omniORB] generated types copy constructor problem

[Duncan Grisby]

On Mon, 2015-04-13 at 16:27 +0200, Michael Teske wrote:

[...]
> 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....

Yes, that it likely to cause trouble too...

> 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.

Yes, and also operator=.

> I understand that this will not make it into omniorb, but i guess
> template.py would be the right location here?

Yes, header/template.py is where you will find the template used for the
generated code.

If you come up with a simple minimal patch, it can be included in
omniORB. The standard says that there is no guarantee what the code does
for uninitialised unions, but it doesn't require it to be actively
hostile. Making omniORB's code robust against these situations is no bad
thing, it's just outside the requirements of the standard.

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --