Cannot use hex numbers in HW links in EPICS 7

Bug #1950300 reported by Dirk Zimoch
6
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.

Revision history for this message
Dirk Zimoch (dirk.zimoch) wrote :
description: updated
Revision history for this message
Dirk Zimoch (dirk.zimoch) wrote :
Revision history for this message
mdavidsaver (mdavidsaver) wrote :

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 :

%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 :

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 :

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 :

> 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

Revision history for this message
mdavidsaver (mdavidsaver) wrote :
Revision history for this message
Andrew Johnson (anj) wrote :

I'd be happy with switching to from %d to %i as long as the PR includes an entry in the Release Notes describing that change.

Revision history for this message
Dirk Zimoch (dirk.zimoch) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.