EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: epicsScanDouble behavior change in R3.15
From: "Priller, John" <[email protected]>
To: "[email protected]" <[email protected]>
Date: Wed, 1 Jul 2015 12:32:15 +0000
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  <20152016  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  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 16 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·