Experimental Physics and Industrial Control System
Subject: |
DBF_STRING to DBF_ENUM/MENU/DEVICE Conversions |
From: |
Andrew Johnson <[email protected]> |
To: |
"EPICS core-talk" <[email protected]> |
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
<2012>
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- 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
<2012>
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024