Michael> Yeah, I should have used a long int. Just one of the things
Michael> I may have "cut corners" on because I was in a hurry. Some
Michael> other implementation decisions that I did not particularly
Michael> like were:
Michael> - in tnmMibFrozen, I traverse the linked list twice,
Michael> once for the enums (old code) and another for
Michael> the ranges (new code); this seems very wasteful
Michael> but I could not think of an elegant way to implement
Michael> this without the double traversal
I changed the TnmMibEnum structure to a TnmMibRest structure which
contains a union for enumerations or ranges. This makes the
tnmMibFrozen.c code a bit shorter and it avoid to have void* pointers.
Michael> - there are some missing error messages, in the switch
Michael> statements, I chose to ignore any problems instead
Michael> of outputting error messages
These are only internal problems if someone adds a new restriction.
This is very unlikely. If I would put something in there, I would
probably use a panic() call.
Michael> - even though the UPTO (..) symbol is defined in the
Michael> keywords array, the parser explicitly looks for
Michael> the (..) instead; again, I couldn't figure out an
Michael> elegant solution without having to make a lot of
Michael> changes
Michael> - the conversion of the bin/hex values in ScanRange
Michael> should probably be put into the parser itself
Michael> instead of being restricted to ranges only
Michael> - I didn't verify sub-ranges are valid; e.g.,
Michael> overlapping ranges (1..10|9..20), ranges that
Michael> exceed those of the parent type, etc.; section
Michael> 13 of RFC1902 discusses these in detail
I did not look at the parser yet. It is know to be ugly and every
effort to really improve it is a waste of time. I hope to replace the
parser and the frozen file stuff with some fancy lex/yacc based code
sometime in the future.
Michael> - my code broke the parsing of rfc1792.mib (line 14)
Michael> because "size" != "SIZE"; I don't believe it is
Michael> specified anywhere that the keywords must be in
Michael> uppercase, therefore, I think the parser should
Michael> compare case-insensitively; if I am wrong, where
Michael> can I find the doc that specifies?
I am 90% sure that it has to be uppercase. This is defined in the
ASN.1 standard which is used to define the SNMP SMI. Anyway, the
parser makes "guesses" at various places to accept real world MIB
definitions. Accepting a case-insensitive SIZE keyword is not likely
to break anything.
Juergen
-- !! This message is brought to you via the `tkined & scotty' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to <tkined-request@ibr.cs.tu-bs.de>. !! See http://wwwsnmp.cs.utwente.nl/~schoenw/scotty/ for more information.