Hi!

Brian> It seems that there is a problem with how the smiRange structure is Brian> populated for a MIB point of the following type:

Brian> Uint32 ::= INTEGER ( 0..4294967295 )

Something like ``INTEGER ( 0..4294967295 )'' must not show up in any regular MIB module, since the INTEGER type is implicitly restricted to (-2147483648..2147483647).

The only exception are those `pseudo modules' that belong to the group of SMI language definition modules: RFC1155-SMI, SNMPv2-SMI, ... And these should be handled correctly. Please, let me know, if not.

Brian> The smiRange structure reports -1 for the minValue.Integer32 Brian> element. The maxValue.Integer32 reports 0. It seems like Brian> these are backward. Obviously, the minValue is equivalent to Brian> 0xFFFFFFFF which is why it appears as -1, but why isn't this Brian> showing up as the maxValue? Am I doing something wrong?

The parsers tries to interpret the numbers as signed numbers, because the underlying basetype (INTEGER) is signed. This makes 4294967295 to be interpreted as -1. Then the parser recognizes that the min and max values have to be exchanged, because min > max. This should have been reported by smilint in a way like this (this first line shows up only for SMIv2 modules):

: use Integer32 instead of INTEGER in SMIv2 : range limit exceeds underlying basetype : range limits must be `lower-bound .. upper-bound'

-frank -- !! This message is brought to you via the `libsmi' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to libsmi-request@ibr.cs.tu-bs.de. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.