[omniORB] Specification of IDL for communication

[Duncan Grisby]

On Tue, 2016-07-05 at 19:32 +0900, 上畠克仁 via omniORB-list wrote:

[...]
> Would this communication be guaranteed in this case?
> (Can this new application communicate with old application ?)

> //Currently working
> struct structureA {
>         string     name_;
>         boolean    jugement_;
>         boolean    reserved_;  *1 *2
> };
> 
> //Newly creating
> struct structureA {
>         string     name_;
>         boolean    jugement_;
>         octet        newValiable_;  *2
> };
> 
> *1 In this structure, 'reserved_' is not used yet.
> *2 This is used between the new things, but it isn't used by the thing
> currently working.

The CORBA specification says that it is illegal to change the IDL like
that.

Really, the question is will you get away with it?  With omniORB as the
receiving side, the answer is yes, although exactly what will happen on
the old server depends on the platform.

Imagine the client sends an octet value 5. The server will receive it,
expecting a boolean. If your compiler supports the C++ bool type (I'll
be surprised if it doesn't!), omniORB will explicitly convert the value
5 to true. If your compiler is truly ancient and doesn't support bool,
then the C++ mapping of boolean is to unsigned char, and omniORB doesn't
validate the value, meaning the application code will see the value 5
when it would have expected only 0 or 1.

Either way, omniORB chooses to be kind to you. It would be compliant for
an ORB to be more strict and throw a MARSHAL exception if it received a
value other than 0 or 1 for a boolean. In that situation, the client's
data would be rejected as invalid even though the server didn't care
about it.

Duncan.

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