Code review comment for ~dirk.zimoch/epics-base:named-events-backward-compatibility
Revision history for this message
| Dirk Zimoch (dirk.zimoch) wrote | # |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
73416ba
(Get the code!)
My original fix was supposed to be minimally invasive: an integer 0-255 followed by ".000000" was treated as a numeric event, with 0 being no event. Then change requests came in.
> Convert in the %f-variant of the %g style: don't show insignificant zeroes to the right of the decimal point, and don't include the decimal point on whole numbers.
I tested three cases for the conversion from a calc[out] with VAL=2.0:
1. event.INP -> calcout.VAL (or calc)
This is no problem. calcout.PREC is used to convert the value, so I get "2" with the default PREC=0.
2. event.INP -> calcout.VAL CP
This uses precision=6! I get "2.000000"
I find this a bit strange because caget -d0 gives me "2".
3. calcout.OUT -> event.VAL
This uses precision=6 as well. I get "2.000000".
Maybe the problem should really be fixed in the conversion double->string. But this may break other stuff. I will investigate a bit...