--------------1CFBAE393F54BC7EFF6D5DF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Whoops, forgot to cc:
--------------1CFBAE393F54BC7EFF6D5DF
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-ID: <348D6AED.15FB7483@summa4.com>
Date: Tue, 09 Dec 1997 10:59:41 -0500
From: "Michael J. Long" <mjlong@summa4.com>
Organization: Summa Four
X-Mailer: Mozilla 3.0 (X11; I; SunOS 4.1.4 sun4m)
MIME-Version: 1.0
To: schoenw@ibr.cs.tu-bs.de
Subject: Re: [tkined] MIB Ranges code (alpha release)
References: <199712090123.CAA04201@molinari.ibr.cs.tu-bs.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Juergen Schoenwaelder wrote:
[...snip...]
> Nice work. I scanned through the diff and there are some things to
> improve. You are using two int variables to store the upper and lower
> bounds of a range. The interesting thing is that you can define ranges
> for Integer32 types as well as Unsigned32 types. This means that you
> can't store the bounds of a range in a structure with two ints - at
> least if you do not want to cast things based on the base type. :-)
Yeah, I should have used a long int. Just one of the things
I may have "cut corners" on because I was in a hurry. Some
other implementation decisions that I did not particularly
like were:
- in tnmMibFrozen, I traverse the linked list twice,
once for the enums (old code) and another for
the ranges (new code); this seems very wasteful
but I could not think of an elegant way to implement
this without the double traversal
- there are some missing error messages, in the switch
statements, I chose to ignore any problems instead
of outputting error messages
- even though the UPTO (..) symbol is defined in the
keywords array, the parser explicitly looks for
the (..) instead; again, I couldn't figure out an
elegant solution without having to make a lot of
changes
- the conversion of the bin/hex values in ScanRange
should probably be put into the parser itself
instead of being restricted to ranges only
- I didn't verify sub-ranges are valid; e.g.,
overlapping ranges (1..10|9..20), ranges that
exceed those of the parent type, etc.; section
13 of RFC1902 discusses these in detail
- my code broke the parsing of rfc1792.mib (line 14)
because "size" != "SIZE"; I don't believe it is
specified anywhere that the keywords must be in
uppercase, therefore, I think the parser should
compare case-insensitively; if I am wrong, where
can I find the doc that specifies?
That's all I can think of right now.
> Anyway, I decided to take this patch as a starting point to integrate
> support for ranges in the upcoming next version. I think I can even
> simplify some things. Watch for it in one of the next snapshots.
I'll be waiting for the next snapshot.
> Thanks again for writing this piece of code,
The way I look at it, we (the scotty community) should be
thanking you for all the hard work you do on scotty.
[...sig snipped...]
Michael J. Long
-- * Michael J. Long * #include <disclaimer.h> * Summa Four * Work: mjlong@Summa4.COM * Manchester, NH * Play: mjlong@mindspring.com--------------1CFBAE393F54BC7EFF6D5DF--
-- !! 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.