CORBA25 — COBRA problem using pragma prefix for modules

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 "omg.org"
> >
> > module CosNaming
> > {
> > typedef string Istring;
> >
> > struct NameComponent
> >

;
> > };
> >
> > #pragma prefix "ooc.com"
> >
> > module CosNaming
> >

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

Absolutely.

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

;

#pragma prefix "Y"
module M

;

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 "omg.org"

module CosNaming
{
typedef string Istring;

struct NameComponent

;
};

module CosNaming

;

> 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

Clarify as described below