On Wed, Jul 12, 2006 at 05:34:41PM +0200, Juergen Schoenwaelder wrote:
On Wed, Jul 12, 2006 at 07:27:47AM -0700, Randy Couey wrote:
Another alternative could be to generate a range which is less strict, that is for [1:1] and [8:8] we could spit out [1:8] which might be better than generating just [8:8]. (Note that libsmi ensures that ranges are in ascending order if I recall correctly, regardless how things were defined in the MIB module.)
That's very similar to how I had been "fixing" the problem previously. For the few clauses where it mattered, I was simply changing SIZE(x|y) to SIZE(x..y). This allowed smidump to create a single range as you described above.
Even though that solution gives better results than before, it's still not correct. I think the list of ranges that I proposed is the best solution, since there is no loss of information.
I might not have been very clear. What I meant is to do what you propose with the minor change that the legacy range element would be indicating the full range and not just the last range element.
I have checked in the modified patch. Here is now what I get for DateAndTime (SNMPv2-TC) which is defined as (SIZE (8 | 11)):
"DateAndTime" : { "basetype" : "OctetString", "status" : "current", "ranges" : [ { "min" : "8", "max" : "8" }, { "min" : "11", "max" : "11" }, ], "range" : { "min" : "8", "max" : "11" },
Thanks for submitting the patch.
/js