Malformed patterns using -f xsd
I use libsmi 0.4.5. When I have a textual convention like this one:
NiceString ::= TEXTUAL-CONVENTION DISPLAY-HINT "1d1d" STATUS current DESCRIPTION "doc" SYNTAX OCTET STRING (SIZE (2))
it gets translated by the -f xsd option into:
<xsd:simpleType name="NiceString"> xsd:annotation xsd:documentation doc </xsd:documentation> xsd:appinfo <displayHint>1d1d</displayHint> <lengths> <length min="2" max="2"/> </lengths> </xsd:appinfo> </xsd:annotation> <xsd:restriction base="xsd:string"> <xsd:pattern value="((0|[1-9](([0-9]){0,2}))((0|[1-9](([0-9]){0,2})))"/> </xsd:restriction> </xsd:simpleType>
Note here that the pattern is malformed: the first opening parenthesis is not closed. The code in getStrDHType which is responsible I find somewhat complicated, but my current fix is to change the line
smiAsprintf( &ret, "%s)", ret ); to smiAsprintf( &ret, "%s))", ret );
This is line 585; the header has * @(#) $Id: dump-xsd.c 2609 2005-07-12 07:44:57Z strauss $
This fix may be in the wrong place, though.
A second problem I encountered while debugging the above is that this definition:
NiceString ::= TEXTUAL-CONVENTION DISPLAY-HINT "1d1d" STATUS current DESCRIPTION "doc" SYNTAX OCTET STRING (SIZE (2 | 2))
causes smidump to hang. In practice this is not a problem - just fix the SIZE specification in the MIB file.
On Thu, Jul 06, 2006 at 01:24:11PM +0200, Arndt Jonasson wrote:
A second problem I encountered while debugging the above is that this definition:
NiceString ::= TEXTUAL-CONVENTION DISPLAY-HINT "1d1d" STATUS current DESCRIPTION "doc" SYNTAX OCTET STRING (SIZE (2 | 2))
causes smidump to hang. In practice this is not a problem - just fix the SIZE specification in the MIB file.
This is an interesting bug and I am surprised that nobody did run into this before.
The problem seems to be in the implementation of smiGetNextRange() which tries to locate the next range element by comparing that start value of the range. Since both range elements start with the same number, smiGetNextRange() always returns the same element. I did not test it, but the restriction (SIZE (2..3| 2..6)) should exhibit the same behaviour.
Since the bug is in the smiGetNextRange() API function, all smidump backends that look at ranges are affected by the bug and not just the xsd backend.
The obvious fix would be to do a pointer comparison rather than comparing values of the lower bound. Frank, do you recall whether there was a reason not to do a pointer comparison here?
/js
Hi Arndt!
Sorry for the late reply.
Arndt Jonasson schrieb:
I use libsmi 0.4.5. When I have a textual convention like this one:
NiceString ::= TEXTUAL-CONVENTION DISPLAY-HINT "1d1d" STATUS current DESCRIPTION "doc" SYNTAX OCTET STRING (SIZE (2))
it gets translated by the -f xsd option into:
<xsd:simpleType name="NiceString"> xsd:annotation xsd:documentation doc </xsd:documentation> xsd:appinfo <displayHint>1d1d</displayHint> <lengths> <length min="2" max="2"/> </lengths> </xsd:appinfo> </xsd:annotation> <xsd:restriction base="xsd:string"> <xsd:pattern value="((0|[1-9](([0-9]){0,2}))((0|[1-9](([0-9]){0,2})))"/> </xsd:restriction> </xsd:simpleType>
Note here that the pattern is malformed: the first opening parenthesis is not closed. The code in getStrDHType which is responsible I find somewhat complicated, but my current fix is to change the line
smiAsprintf( &ret, "%s)", ret );to smiAsprintf( &ret, "%s))", ret );
This is line 585; the header has
- @(#) $Id: dump-xsd.c 2609 2005-07-12 07:44:57Z strauss $
This fix may be in the wrong place, though.
Thanks for pointing this out. Yes, the code is very complicated. I have added a check for unclosed parenthesis at the end of the method. I am aware that this is only a quick-fix which will probably not help in all possible cases.
Best regards, Torsten
participants (3)
-
Arndt Jonasson -
Juergen Schoenwaelder -
Torsten Klie