I have code that uses epicsScanDouble to convert a string-representation
of floating point numbers to actual floating-point, and I've found
there's a behavior change from R3.14.12.2 to R3.15 (either .1 or .2)
I wrote a simple little test program to demonstrate it, the output for
R3.14.12.2 looks like this:
EPICS 3.14.12.2 epicsScanDouble test
status: 1 value: 3.1415 for input string: ' 3.1415 '
status: 1 value: 6.022e+23 for input string: ' 6.022e+23 '
status: 0 value: 0 for input string: ' bob '
status: 1 value: 5.43 for input string: ' 5.43V '
status: 1 value: 6.78 for input string: ' 6.78 A '
But under R3.15.2 I get:
EPICS 3.15.2 epicsScanDouble test
status: 1 value: 3.1415 for input string: ' 3.1415 '
status: 1 value: 6.022e+23 for input string: ' 6.022e+23 '
status: 0 value: 0 for input string: ' bob '
status: 0 value: 0 for input string: ' 5.43V '
status: 0 value: 0 for input string: ' 6.78 A '
Skimming the source it appears that epicsScanDouble is now a macro
calling epicsParseDouble with a units pointer of NULL. If I call
epicsParseDouble directly with units=NULL this does indeed fail, but if
I pass it a valid pointer it then succeeds.
So, question: was this an intentional change, that units/etc off the end
of the number string now cause epicsScanDouble to fail? I can
#if/#else the code to call epicsParseDouble if it's available, and I
guess I'll have to do that for now, but that's the sort of version
dependency I'd like to avoid if at all possible.
Any feedback appreciated, even if it's "no, you're doing it all wrong..."
--
John A. Priller | Phone : (517) 908-7375
MSU Cyclotron Laboratory | Email : [email protected]
640 S. Shaw Lane room 4220Z | Web : http://people.nscl.msu.edu/~priller/
East Lansing, MI 48824 |
- Replies:
- Re: epicsScanDouble behavior change in R3.15 Andrew Johnson
- Navigate by Date:
- Prev:
Re: epicsExit (); function exits the IOC but the Linux console requires a resest to be operative Diego Sanz
- Next:
Re: epicsScanDouble behavior change in R3.15 Andrew Johnson
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
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:
RE: autosave ---Data coverage Mooney, Tim M.
- Next:
Re: epicsScanDouble behavior change in R3.15 Andrew Johnson
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
<2015>
2016
2017
2018
2019
2020
2021
2022
2023
2024
|