An user opened an issue about problems in parsing an USBTMC transport string of format "usbtmc[:vendorid=0x1313][:productid=0x8075]:serialnr=Pxxxxxxx". The string is incorrect so the problem was not in the parsing, but what caused the user to think this would be a valid string is that:
a) The documentation does not state the parts between "[...]" are optional inputs
b) For USBTMC all inputs are obligatory, but the example string shows the contrary!
c) r"(?::\[(.+)[\]$])|" # enclosed parameter (for example used in ipv6): i.e. ...:[param]:... or ...:[param] line in parsing implies [ and ] would be allowed inputs.
We should fix the documentation such that:
a) Write clearly that the parts between "[...]" are for giving an IPv6 address for TCP transports.
b) Remove the incorrect optional parts of USBTMC device's string format, and also the =0x... and =sn parts, as they are explained below. Besides, =0x... suggests that the format has to be hex, while decimal (int) is also fine.
c) This is valid, as for TCP transports with IPv6 addresses the square brackets are used to distinct the : characters in the IPv6 address from the : characters in the transport string. But it is confusing to use the same character to imply optional input and the IPv6 address delimiter. So, probably it would be useful to use some other character, say < and > to imply the optional inputs.
Modules to be modified
qmi.core.transport
CHANGELOG.md
Tests to be created or updated
tests.core.test_transport to either catch an error if square brackets are used, or, if "fixed", to test that the use of square brackets works correctly.
Description
An user opened an issue about problems in parsing an USBTMC transport string of format "usbtmc[:vendorid=0x1313][:productid=0x8075]:serialnr=Pxxxxxxx". The string is incorrect so the problem was not in the parsing, but what caused the user to think this would be a valid string is that: a) The documentation does not state the parts between "[...]" are optional inputs b) For USBTMC all inputs are obligatory, but the example string shows the contrary! c)
r"(?::\[(.+)[\]$])|" # enclosed parameter (for example used in ipv6): i.e. ...:[param]:... or ...:[param]line in parsing implies[and]would be allowed inputs.We should fix the documentation such that: a) Write clearly that the parts between "[...]" are for giving an IPv6 address for TCP transports. b) Remove the incorrect optional parts of USBTMC device's string format, and also the
=0x...and=snparts, as they are explained below. Besides,=0x...suggests that the format has to behex, while decimal (int) is also fine. c) This is valid, as for TCP transports with IPv6 addresses the square brackets are used to distinct the:characters in the IPv6 address from the:characters in the transport string. But it is confusing to use the same character to imply optional input and the IPv6 address delimiter. So, probably it would be useful to use some other character, say<and>to imply the optional inputs.Modules to be modified
qmi.core.transportCHANGELOG.mdTests to be created or updated
tests.core.test_transportto either catch an error if square brackets are used, or, if "fixed", to test that the use of square brackets works correctly.