EPICS Base

Cannot use hex numbers in HW links in EPICS 7

Bug #1950300 reported by Dirk Zimoch on 2021-11-09

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	EPICS Base	New	Undecided	Unassigned

Bug Description

In EPICS 3.14.12, it was possible to use hex numbers in hardware links of type VME_IO and others like "#C0 S0x8b". (The parser used the function cvtDecimalOrHexToShort for this.) In EPICS 7 this does not work any longer because the string is parsed with %d instead of %i. As many of our existing IOCs use hex numbers here, this makes transition to EPICS 7 unnecessary hard.

Changing to %i will allow hex numbers, but will also allow octal numbers. That may a problem as C011 uses to mean 11 in 3.14, not 9.

In that case, parsing with a single sscanf is not sufficient.

See original description

Revision history for this message

Dirk Zimoch (dirk.zimoch) wrote on 2021-11-09:

hexInLinks.patch Edit (877 bytes, text/plain)

Dirk Zimoch (dirk.zimoch) on 2021-11-09

description:

updated

Revision history for this message

Dirk Zimoch (dirk.zimoch) wrote on 2021-11-09:

hexInLinks.patch Edit (1.7 KiB, text/plain)

Revision history for this message

mdavidsaver (mdavidsaver) wrote on 2021-11-09:

I hadn't known about '%i' with scanf().

Are you (Dirk) going to create a github PR so that new test case is run through CI?

Have you investigated portability? Is '%i' mentioned in the C89 spec.?

A quick search finds that '%i' is documented by MS [1]. And [2] claims it is "... supported by the latest C and C++ standards (both published in 2011) ...". So this looks fine going forward.

[1] https://docs.microsoft.com/en-us/cpp/c-runtime-library/scanf-type-field-characters?view=msvc-170
[2] https://www.cplusplus.com/reference/cstdio/scanf/?kw=scanf

Revision history for this message

Dirk Zimoch (dirk.zimoch) wrote on 2021-11-09:

%i has been available in the scanf function familiy for as long as I do C. It works in vxWorks, Windows, Linux. The Linux man page does not mention anything special or version dependent about %i, but I do not know the standards.
To my surprise the EPICS 7 code base does not use it so far, but EPICS 3.14.12 has it in src/gdd/aitConvert.cc.

My biggest concern is not that any sscanf version does not understand %i. It is rather that it may interpret numbers starting with 0 as octal when they are not meant that way and had not been interpreted as octal in EPICS 3.14.

Revision history for this message

Dirk Zimoch (dirk.zimoch) wrote on 2021-11-09:

In 3.14, missing arguments instead of 0 were allowed as well: "#C S2" worked and was interpreted as "#C0 S2". This will not work with sscanf even when using %i.

Revision history for this message

Dirk Zimoch (dirk.zimoch) wrote on 2021-11-09:

I can create a PR but need to know which way to go. I would probably aim for EPICS 3.14 compatibility. That would mean to drop the sscanf approach and go back to a cvtDecimalOrHexToShort function or something similar.

Revision history for this message

mdavidsaver (mdavidsaver) wrote on 2021-11-09:

> EPICS 3.14.12 has it in src/gdd/aitConvert.cc.

Ok, this is enough for me wrt. compatibility.

> In 3.14, missing arguments instead of 0 were allowed as well: "#C S2" ...

The change to acceptable link syntax dates to 2014 [2]. It was understood and accepted at the time that making the parser stricter could break some existing databases.

> I can create a PR but need to know which way to go. ...

I would encourage you to push this small change through before trying for something larger.

I don't see the change in interpretation of eg. "#C010 S1 @" as octal to be a likely issue. Although it might be argued that it is less obvious as it doesn't result in an error.

[1] https://code.launchpad.net/~epics-core/epics-base/link-parsing/+merge/229252