[omniORB] Inconsistent enum return behavior

[Duncan Grisby]

On Thu, 2016-06-23 at 18:30 +0200, Peter Klotz via omniORB-list wrote:

> Consider this IDL file shared by a client and a server:
> 
> enum Color { COL_WHITE };
> typedef sequence<Color> Colors;
> Color f();
> Colors g();
> 
> Later someone alters the IDL file by adding an enum value:
> 
> enum Color { COL_WHITE, COL_BLACK };

> The server uses the new IDL file and returns COL_BLACK when f() is
> called and a sequence with one element that is COL_BLACK when g() is
> called.
> 
> A client still using the old interface behaves inconsistent.
> 
> client calls f(): A MARSHAL exception with minor code
> MARSHAL_InvalidEnumValue is thrown by omniORB

> client calls g(): Value 1 (which equals COL_BLACK) is received by the
> client. No exception is thrown. The interface inconsistency goes
> undetected.
> 
> Is this behavior correct?

It is correct, in that it is not an accident that it behaves that way,
and it is compliant with the CORBA spec. I agree that it's surprising
though. The CORBA spec doesn't say what should happen with an invalid
enum item. It's clearly illegal to change IDL in this way, but the spec
doesn't say how to handle people who break the law.

The reason for the difference is that when unmarshalling a single enum,
omniORB checks it against the expected range, and throws the exception
if it's out of range. However, when unmarshalling a sequence of them, it
uses an optimised code path that does a bulk read into the sequence
buffer. It doesn't iterate over the values to check them for validity,
because that would make it significantly slower if the sequence was
large.

Duncan.

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