-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Protect against overflow/underflow for integer record types #110
base: master
Are you sure you want to change the base?
Conversation
Codecov Report
@@ Coverage Diff @@
## master #110 +/- ##
==========================================
- Coverage 87.03% 86.90% -0.14%
==========================================
Files 14 14
Lines 972 985 +13
==========================================
+ Hits 846 856 +10
- Misses 126 129 +3
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
Thinking about it, in its current form this PR does mean you can no longer signal a boolOut/mbbOut record is in an invalid state by setting an out-of-range number to trigger the "ILLEGAL VALUE" error handling in EPICS. That's related to issue #53. I don't know if this is a significant concern. |
Long records restricted to int32 min/max, bool to 0 or 1, mbb to 0-15.
This will cause data validation to occur for caput'd values Also fix tests (previously we were putting invalid values to bool records)
Note we have to skip mbbOut record testing, as for some reason cothread caput succeeds for this record type but not for the others
6d06d27
to
9c19bed
Compare
Long, Bool and MBB record types are now protected from out of range values -
.set()
will throw an exception, andcaput()
will fail to store the new value. This means records can no longer be put into invalid values, or suffer from integer overflow/underflow.Also correct an oversight in
get_field_offsets
, to properly raise a Python exception when the record type cannot be found.Closes #66