CORBA 2.5 NO IDEA Avatar
  1. OMG Issue

CORBA25 — COBRA problem using pragma prefix for modules

  • Key: CORBA25-41
  • Legacy Issue Number: 4395
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Please have a look at the news article below. Basically, the problem is
    that we don't say in the spec what has to happen if I try to give
    conflicting prefixes/IDs/versions to a module (which can happen if a module
    is reopened).

    My feeling is that we should deal with this the same way as for forward
    declarations, that is, force the compiler to emit a diagnostic. I think
    we should also add a note that this can't be enforced by the compiler
    under all circumstances because of separate compilation.
    > Orbacus distribution contains following IDL file.
    > > #pragma prefix ""
    > >
    > > module CosNaming
    > > {
    > > typedef string Istring;
    > >
    > > struct NameComponent
    > >

    { > > Istring id; > > Istring kind; > > }

    > > };
    > >
    > > #pragma prefix ""
    > >
    > > module CosNaming
    > >

    { > > typedef string Ostring; > > }

    > And here the error message of IDL to Visual Basic compiler.
    > orbacusnaming.idl:16(8): Attempt to assign a different prefix
    > to a forward-declared identifier
    > orbacusnaming.idl:3(8): Position of the first identifier definition

    The error message is misleading becuase there is no forward-declared
    identifier here. But the compiler has a point – something strange is
    going on there...

    > I look in the CORBA specification and found that modules do have
    > repository ids.


    > > Forward-declared constructs (interfaces, value types, structures,
    > > and unions) must have the same prefix in effect wherever
    > > they appear. Attempts to assign conflicting prefixes
    > > to a forward-declared construct result in a compile-time
    > > diagnostic. For example:
    > [...]
    > And what about reopened modules?

    This part of the spec simply doesn't apply because it talks about
    forward-declared things only.

    > Which repository id do they
    > have if someone use different prefix statements? I think
    > they can have only one because the IFR of CORBA allows only
    > one (if the repository version is equal).

    Yes. The spec isn't really clear on this point. Here is your example
    once more, simplified to the bare bones:

    #pragma prefix "X"
    module M

    { typedef string foo; }


    #pragma prefix "Y"
    module M

    { typedef string var; }


    The spec simply does not address this problem, so we have a hole. Thinking
    about it, there are two possible interpretations:

    1) Module M gets a prefix "X" initially. Then, when the prefix
    changes to "Y" and the compiler sees M for the second time,
    it could just ignore the prefix for M because M has the prefix
    "X" already.

    2) The compiler could notice that M previously got prefix "X"
    and then complain when it sees M for the second time because
    it would get a conflicting prefix.

    For forward-declared things, the spec applies the philosophy that
    the prefixes must not change. Seeing that a reopened module is somewhat
    similar to a forward declaration (because the same definition can be seen
    more than once), I'd be inclined to amend the spec to say that the prefix
    for a module must not change.

    For cases where the compiler can actually detect this, we can even force
    a diagnostic. However, as for forward-declared things, this is not always
    detectable by the compiler. In particular, if the reopened module is
    reopened in different source files and the two source files are compiled
    separately, there is no way for the compiler to detect that the module
    is getting a different prefix in each source file. If the generated code
    from the two files is linked into the same binary, you should at least
    get a multiple definition error. But if the code for the two files ends
    up in different executables, there is no way to detect the error at all
    and you will get strange things happening at run time.

    As far as the ORBAcus IDL is concerned, I think it needs fixing. The second
    prefix pragma should be inside the module, to avoid the conflict:

    #pragma prefix ""

    module CosNaming
    typedef string Istring;

    struct NameComponent

    { Istring id; Istring kind; }


    module CosNaming

    { #pragma prefix "" typedef string Ostring; }


    > Is my IDL2VB compiler again buggy or the Orbacus IDL file
    > or the CORBA specification not clear?

    Well, a little bit of all three I'll raise an issue with the core RTF.

    > I recently solve all founded bugs in IDL2VB and it compiles now
    > all examples of syntax chapter in CORBA spec and find
    > all errors. CORBA is to difficult for humans...

    That's why we use compilers for IDL instead of humans

  • Reported: CORBA 2.4.2 — Sun, 24 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Clarify as described below

  • Updated: Fri, 6 Mar 2015 20:58 GMT