Re: Some additional obscure questions...

[Michael Kirkham <mikek@muonics.com>]

On Thu, 6 Feb 2003, Bob Natale wrote:

> >Indeed,
> >the compiler won't even know whether such a DEFVAL
> >is of the correct data type until that subsequent object
> >definition has been processed.
>
> I honestly can't follow that statement.  In your
> example, the DEFVAL value *must* either devolve
> to an OID or fail to devolve to anything.  The
> only possible *type* for any DEFVAL is explicitly
> defined by the SYNTAX clause of its OBJECT-TYPE
> definition.  Isn't it?

With regards specifically this this statement/question:

DEFVAL-EXAMPLE-MIB DEFINITIONS ::= BEGIN
IMPORTS
   OBJECT-TYPE
      FROM SNMPv2-SMI
   TruthValue
      FROM SNMPv2-TC
   ...
   ;

   ...

   trueOrFalse OBJECT-TYPE
      SYNTAX TruthValue
      ...
      DEFVAL { false }
      ::= { ... }
END

A parser won't generally know what it sees 'false' here whether that is a
reference to an OID value or whether it is an enumeration label.  In
theory it *could* if you did all your parsing manually instead of using a
parser generator with, say, only 1 lookahead token, and you went through
and resolved every possible thing as you parsed it (e.g., you see "SYNTAX
TruthValue' and go look up TruthValue and copied its information into the
OBJECT-TYPE's definition internally).  But that would seem to me to be way
more complicated.  And, not only that, but then you'd definitely have to
consider type references to be forward referencing too (and there I would
point back to the table-based example I gave with the order of the
sequence type/table/row/columns being at issue).

Whether or not this falls into the common definition of a forward
reference is probably debatable.  Depending on the implementation, the
definition of 'TruthValue' may or may not be known at the time this object
is parsed.  But I doubt many compiler implementations are going to try to
figure out what 'false' means immediately upon parsing it.  They're going
to save it off somewhere in internal data structures to deal with once
everything is parsed, at which point it can do post-processing stuff that
includes verifying that 'false' is an okay DEFVAL for this object.  In
order to do that, the compiler is going to have to retain some of the
symbolic nature of the parsed data and resolve 'false' later through
implementation-specific algorithms.

Resolving things after the parsing phase, as opposed to during, qualifies
as forward-referencing in my book.  Perhaps not yours and that's why we've
got some disagreement on some of the issues.

> I am not aware of any MIB design constraints --
> unless there are going to be more of these
> "circular" examples -- in which the OBJECTS
> used in a NOTIFICATION-TYPE definition could
> not be defined prior to the NOTIFICATION-TYPE
> using a "better" (i.e., more consistent with
> the concept of "naming hierarchy").  Are there
> any?

To be honest, I haven't been able to think of any normally-occuring
situations where it is impossible to define a MIB module without forward
references for OID assignments (::= etc. -- that is, excluding all of the
other references to OID values except those that assign values to
descriptors as in macro invocations).

This isn't, IMHO, sufficient reason not to support them, however.  Not
supporting them just means that someone, somewhere, will get to deal with
the headache when their MIB doesn't work with a particular compiler
because they put 'b' before 'a'.

It's also possible to write modules such that they're impossible to deal
with without handling forward references; but those are exactly the
"circular" examples, which may be contrived to varying degrees.  If
there's no circular nature to it, then it must be linear and can be
reordered, right? :)

If it makes you feel any better, my implementation generates SMI modules
with assignments in order of increasing OID for compatibility with those
that don't support forward references.  That helps with the 'b' before 'a'
issue, but doesn't get you anywhere with circular references.

As a postscript, and likely another contrived example, I'll mention a that
not too long ago there was some discussion about whether or not it was
legal to, for example, have an OBJECT-TYPE defined under the OBJECT-GROUP
in which it is contained.  Consensus was that it is legal, but not a
particularly good idea for several reasons.  Now, I don't know of any
modules offhand that do this, so you can consider it a contrived example
if you wish, but that would tend toward forward references (and, of
course, a "circular" example, because I believe "circular" is a
requirement to meet your definition of a forward reference).

--
Michael Kirkham
www.muonics.com