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 | 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 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: mask for bitwise operation in CALC record |
From: | Dirk Zimoch <[email protected]> |
To: | Eric Norum <[email protected]> |
Cc: | [email protected] |
Date: | Wed, 06 Jun 2012 12:09:20 +0200 |
Eric Norum wrote:
On Jun 5, 2012, at 9:46 AM, Andrew Johnson wrote:Hi Eric, On Jun 5, 2012, at 6:11 AM, Dirk Zimoch wrote:I think adding something like this to epicsStrtod should fix the problem: if (epicsStrnCaseCmp("0x", cp, 2) == 0) { return (double)strtoul(str, endp, 16); }I'll be using strtol() instead in the 3.15 code, so -0x1 works.Right.
I had assumed that the primary application for hex numbers would be bit masks. Signed masks do not make much sense but 0x80000000 does make sense. Maybe we should test for minus and then either call strtol() or strtoul().
On 2012-06-05 Eric Norum wrote:The code with that change doesn't completely match the semantics of strtod as presented in the C99 standard, but it's certainly better than the current code.What else are we missing? I don't have the C99 standard to look at here.A '0x' number can have a fractional part and an exponent. This seems pretty esoteric so its absence is, IMHO, minor.
Nobody right in his mind uses hexadecimal floating point numbers. ;-)
The wording in the vxWorks 6.8 manpage is exactly the same as Dirk posted from vxWorks 5.5.BTW -- does vxWorks still not supply a working strtod? I think that it is the only system that doesn't just define epicsStrtod as strtod.:-(
My argument is: Yes, vxWorks 5.5 still does not supply a working strtod. Changing the vxWorks version is not as simple as upgrading Ubuntu.
No, we use our version of epicsStrtod() on Windows, Cygwin, vxWorks and Solaris. I have a branch for 3.15 where I've been working on the numeric conversions, I'll add some tests for the native strtod().Yuck. After over 12 years they still can't produce a strtod that matches the standard? (!!!)
They are WindRiver (or rather Intel now). They make their own standard.