Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Fri, 27 Jan 2012 12:08:49 -0600

To core-talk readers with opinions, please discuss the following.

Yesterday I responded to a bug report from Josh Stein on tech-talk about dbpf 
not accepting integers when setting a bi.VAL field, which is a DBF_ENUM.  His 
issue turned out to be an extraneous ! operator in the dbpf code (from a 
refactoring of mine in about 2008) combined with what appears to be a bug in 
the MinGW implementation of sscanf().  I posted a patch to the Known Problems 
page which fixes dbpf and changes the STRING to ENUM/MENU/DEVICE conversion 
routines, but I am not sure the latter changes are right.

Both dbConvert.c and dbFastLinkConv.c use the conversion string " %u %n" but 
on MinGW sscanf() doesn't set the argument corresponding to the %n when there 
are no spaces after the unsigned value in the string being converted.  The 
space before the %u is unnecessary and can be safely removed since %u skips 
leading white-space.  The space after the %u directive was included to skip 
any trailing white-space.  The converters compare the value returned by the %n 
directive with strlen() to make sure that only white-space characters follow 
the number.

All of the other string to numeric conversion routines ignore any extraneous 
characters that appear after the number.  I suspect the ENUM/MENU/DEVICE 
conversions do not allow extraneous text to avoid the following, which happens 
if I remove the %n and strlen() check from the current code to make these 
match the other conversion routines:

epics> dbpf anjHost:bi.SCAN "5 seconds"
DBR_STRING:          "2 second"         

This would obviously not be a good thing, so I have abandoned that idea.

The simple patch I posted yesterday changes the conversion format strings from 
" %u %n" to "%u%n" which disallows trailing spaces completely (when putting 
strings containing an integer to an ENUM/MENU/DEVICE field; other conversions 
are not affected).  This changes the conversion behavior of the IOC subtly, 
but I think it's acceptable.  Any other workaround for the MinGW sscanf() 
problem will involve adding code to check for trailing spaces ourselves — not 
hard, but a bit fiddly.

Does anyone object to the simple solution?

- Andrew
-- 
Optimization is the process of taking something that works and
replacing it with something that almost works, but costs less.
-- Roger Needham

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System