g+
g+ Communities
Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014 
<== Date ==> <== Thread ==>

Subject: DBF_STRING to DBF_ENUM/MENU/DEVICE Conversions
From: Andrew Johnson <anj@aps.anl.gov>
To: "EPICS core-talk" <core-talk@aps.anl.gov>
Date: 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


Navigate by Date:
Prev: [Merge] lp:~jlmuir/epics-base/iocsh-comment-fix-3.14 into lp:epics-base/3.14 J. Lewis Muir
Next: [Merge] lp:~anj/epics-base/compiled-dbd into lp:epics-base Andrew Johnson
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014 
Navigate by Thread:
Prev: [Merge] lp:~jlmuir/epics-base/iocsh-comment-fix-3.14 into lp:epics-base/3.14 J. Lewis Muir
Next: [Merge] lp:~anj/epics-base/compiled-dbd into lp:epics-base Andrew Johnson
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014 
ANJ, 26 Nov 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICSv4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·