Re: CA Gateway converts int/float value to hex

["Johnson, Andrew N. via Tech-talk" <tech-talk at aps.anl.gov>]

Hi Andrej,

On Jul 28, 2021, at 3:41 PM, andrej.manojlovic--- via Tech-talk <tech-talk at aps.anl.gov> wrote:

I've encountered a situation with CA Gateway where a `caput` to PV through
Gateway behaves differently compared to a `caput` directly to IOC, bypassing the gateway.

If I caput to an IOC (no Gateway involved):
$ EPICS_CA_ADDR_LIST=ioc_address caput x:ai 10w
The record will store the value 10. The excess 'w' character at the end is
ignored, which is OK.

However when doing the same through CA Gateway:
$ EPICS_CA_ADDR_LIST=gateway_address caput x:ai 10w
The 'w' character at the end will cause the record to store value 16 (10 hex),
which I don't expect. The 'w' is just an example and can be replaced by a
string.

Is this implicit conversion to hex known behavior when using CA Gateway? Can it
be changed to behave the same way as a caput directly to IOC behaves?

Interesting, I agree that this is strange behavior.

It is happening because caput sends the value as a string, and the gateway is apparently converting the string to a double to match the target PV before forwarding the put operation. Unfortunately the C++ code in what I assume is the gateway’s conversion routine (in pcas/src/gdd/aitConvert.cc) looks like this:

            int j = epicsScanDouble( pString, &ftmp );

            if ( j != 1 ) {

                    j = sscanf ( pString,"%x", &itmp );

            if ( j == 1 ) {

                ftmp = itmp;

            }

            else {

                return false;

            }

The epicsScanDouble() call returns 0 if there any extraneous characters are found in the string, and in that case the code tries again using the “%x” format, and as long as that manages to convert some of the string it accepts the hex version. An older version of this code (pre-2004) called sscanf() with a “%lf” format instead of using epicsScanDouble(). With that version extraneous characters would not have caused the first conversion attempt to fail, so the hex conversion would not have been attempted.

The switch to epicsScanDouble() happened in this commit to the pcas module:

commit 0dc034962ccae79fd7fdcfddead52496c837014a

Author: W. Eric Norum <wenorum at lbl.gov>

Date:   Tue Oct 12 17:45:31 2004 +0000

    Use epicsScanFloat/epicsScanDouble rather than sscanf.

    This allows proper handling of Nan/Inf on all architectures.

At that time some EPICS architectures (probably Windows) didn’t convert Inf and Nan properly, so I can understand why the change was done, but I suspect it could be undone here (the other changes in the same commit were outside of the pcas & gdd code).

At this point Ralph Lange will need to comment and decide what to do about this, and in the meantime you could undo that change, rebuild the gateway and report back whether that fixes the problem.

Thanks for the bug report!

- Andrew

-- 

Complexity comes for free, simplicity you have to work for.