[omniORB] IDL formal parameter name clash

Duncan Grisby duncan at grisby.org
Fri Apr 29 12:57:01 BST 2005


On Friday 29 April, Brian Wallis wrote:

>   module aSAP {
>       typedef long ASAP_T;
>   };
> 
>   interface Test {
>       void getASAP(
>           in string aSAPName,
>           out aSAP::ASAP_T aSAP);
>   };
> 
> I get the following error:
> % omniidl -bpython test.idl
> test.idl:8: Declaration of parameter 'aSAP' clashes with use of identifier 
> 'aSAP'
> test.idl:8:  ('aSAP' used here)
> omniidl: 1 error.
> 
> The IDL is a simplification of some IDL from the TMForum's TMF814 interface 
> definition (version 3.0) and I believe it is correct.
> 
> I cannot find anything in the corba spec that would lead me to believe
> that a formal parameter name should clash with a module name as
> implied by the error.

omniidl is correct. Using the module name introduces it into the scope
of the operation parameters. See section 3.15.2 of the CORBA 2.6 spec.
It says:

----------

3.15.2   Scoping Rules and Name Resolution

...

... The scope of an operation begins immediately following its `(` and
ends immediately preceding its closing `)'...

...

An identifier from a surrounding scope is introduced into a scope if
it is used in that scope. An identifier is not introduced into a scope
by merely being visible in that scope. The use of a scoped name
introduces the identifier of the outermost scope of the scoped name.
For example in:

module M {
      module Inner1 {
            typedef string S1;
      };
      module Inner2 {
            typedef string inner1;        // OK
      };
}

The declaration of Inner2::inner1 is OK because the identifier Inner1,
while visible in module Inner2, has not been introduced into module
Inner2 by actual use of it. On the other hand, if module Inner2 were:

module Inner2{
      typedef Inner1::S1 S2;              // Inner1 introduced
      typedef string inner1;              // Error
      typedef string S1;                  // OK
};

The definition of inner1 is now an error because the identifier Inner1
referring to the module Inner1 has been introduced in the scope of
module Inner2 in the first line of the module declaration . Also, the
declaration of S1 in the last line is OK since the identifier S1 was
not introduced into the scope by the use of Inner1::S1 in the first
line.

----------

omniidl is much more strict than most IDL compilers.

Cheers,

Duncan.

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



More information about the omniORB-list mailing list