[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Some additional obscure questions...



One last motivational example on the subject of forward references:

EXAMPLE-MIB DEFINITIONS ::= BEGIN
IMPORTS
   ambiguous
      FROM OTHER-MIB
   experimental, OBJECT-TYPE
      FROM SNMPv2-SMI
   ...
   ;

   someObject1 OBJECT-TYPE
      ...
      ::= { ambiguous 1 }

   ambiguous OBJECT IDENTIFIER ::= { experimental 99999 }

   someObject2 OBJECT-TYPE
      ...
      ::= { OTHER-MIB.ambiguous 1 }

   ...

END

OTHER-MIB DEFINITIONS ::= BEGIN
IMPORTS
   experimental FROM SNMPv2-SMI
   ...
   ;

   ambiguous OBJECT IDENTIFIER ::= { experimental 55555 }

   ...

END

I'll grant that this is still a contrived example, since EXAMPLE-MIB
clearly has knowledge of the fact that it's importing a descriptor that it
defines locally and would not have given the same descriptor to the local
definition.  However, it serves well to illustrate something that the
other examples don't.

[I wouldn't say the { OTHER-MIB.ambiguous 1 } thing is contrived, since
RFC 2578 (3.2) indicates that it is allowed, even though it's not common
usage (I don't think I've ever come across a module that used it other
than those I've created for testing purposes) and many compilers don't
support it.]

If an implementation doesn't support forward references, but does attempt
to support 'module.descriptor' form and tries to resolve EXAMPLE-MIB's
definitions in a single pass, then it's likely that such an implementation
would interpret someObject1 and someObject2 as having the same OID
(experimental.55555.1).  It should be fairly clear that someObject1 should
be experimental.99999.1 and someObject2 should be experimental.55555.1.

Certainly you could change the order of the definitions here, such that
EXAMPLE-MIB.ambiguous is defined before someObject1, and the
implementation would resolve it correctly.  However, the key difference
here is that, unlike the other examples that would typically generate an
error in a non-forward-referencing compiler that indicated something
wasn't defined, in this case it would likely accept both orderings and
generate inconsistent output (valid in one case, invalid in the other).

I would assert that it is not possible to correctly support
'module.descriptor' references in the general case with a
non-forward-referencing parser/compiler.  Failing to compile a module that
uses other types of forward references that it won't fail if reordered is
one thing.  Generating the wrong result is entirely another.  In the
above, such a compiler would probably still generate an error because two
objects are (to the compiler's perspective) defined with the same OID.
However, change the last subidentifier for one of those objects to another
number, and you wouldn't get an error.  You would, however, still have
someObject1 in the wrong branch of the OID tree.

I think that's the best I can come up with.

--
Michael Kirkham
www.muonics.com