Comment 3 for bug 1699445

The IOC sees the link as a constant, but can't convert the hex as you say:

epics> dbpr LI:HEX 1
...
HOPR: 0 HSV: NO_ALARM HYST: 0 INP:CONSTANT 0x0200
...
UDF: 0 UDFS: INVALID VAL: 0

@Ralph you're right up until the dbFastConvertRoutine[][] part, but putStringLong() is from dbConvert.c; the Fast convert routines are found in dbFastLinkConv.c and in the above case it is cvt_st_l() which handles the conversion. The 3.15 version calls strtol(from, &end, 10) where the explicit base=10 argument tells it not to allow hex numbers at all. As long as at least one valid digit is seen cvt_st_l() does not return an error (because that's the way it has always worked).

In Base-3.16.1 both dbConvert.c and dbFastLinkConv.c have already been converted to use the new epicsParseXxx() routines, so here cvt_st_l() calls epicsParseInt32(from, to, 10, &end) which is also passing base=10 with the same effect.

The fix has to be to provide another conversion table for dbConstLoadLink() [which became dbConstLoadScalar() in 3.16.1] that does allow hex numbers.

Base-3.16.1 also accepts arrays [1,2,3] as constants, and there the number parsing is done by the JSON parser; the JSON spec doesn't allow hex numbers though, so no hex arrays. However there is a proposed JSON5 extension (see http://json5.org/ for details) which looks a lot more like my "relaxed JSON" and does allow hex. I would be willing to switch to that standard; there may even be patches available for the yajl parser.