Skip to content
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.

Sign up for GitHub

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

Jump to bottom

No protection against overflow/underflow when setting values #66

Open
AlexanderWells-diamond opened this issue Dec 1, 2021 · 5 comments · May be fixed by #110
Open

No protection against overflow/underflow when setting values #66

AlexanderWells-diamond opened this issue Dec 1, 2021 · 5 comments · May be fixed by #110
Labels
bug

Comments

@AlexanderWells-diamond
Copy link
Collaborator

pythonSoftIOC provides no protections against overflowing data type limits.

The most obvious example of this is longIn/Out, due to the unbounded size of Python3's int type. No warning or error is raised if you attempt to do the following:

builder.longOut("TEST", initial_value=9999999999999)

[...]$ caget TEST
PREFIX:TEST 1316134911

The value is truncated, but no warning is given.

This issue should also investigate all other types, and consider adding validation to the incoming values before passing to EPICS.
Possibilities include ( but are not limited to):

  • Huge floating point values
  • Tiny floating point values
  • Strings that may be silently truncated, especially when unicode is in use
  • Waveforms when the value being set is longer than the NELM of the record
@AlexanderWells-diamond
Copy link
Collaborator Author

As of PR #60 the Waveform (and longString) records do have protections against too long values, but other records have no such protections.

@AlexanderWells-diamond
Copy link
Collaborator Author

Commit 53f107d includes protection for StringIn/Out records. Other issues may still exist in other record types.

AlexanderWells-diamond added a commit that referenced this issue Feb 3, 2022
@AlexanderWells-diamond
Add tests for 53f107d, related to issues #46 & #66
5f14ca3
@Araneidae
Copy link
Collaborator

The following record types will not have protection against invalid or out of range values:

  • bi, bo: any unsigned 16-bit value can be written to these records; this should probably be limited to 0 or 1 as valid values
  • mbbi, mbbo: again, any unsigned 16-bit value can be written; these should probably be limited to numbers in the range 0 to 15 (valid enum values)

All other record types are automatically limited by the current implementation.

@AlexanderWells-diamond
Copy link
Collaborator Author

I think we also want to protect longIn/longOut records from people trying to put values that are too large to properly represent in EPICS. At the least a warning should be printed.
I'm not familiar enough with EPICS's vs Python's representation of floats to know whether protection is also warranted on the same grounds for aIn/aOut records.

@Araneidae
Copy link
Collaborator

Araneidae commented Feb 16, 2022 •
edited
Loading

Oh drat. Didn't realise that long records are quietly truncated to 32 bits. I agree, also needs to be addressed.

Shouldn't be an issue with ai/ao records, the underlying representation is 64-bit IEEE 754 floating point numters in either case.

@AlexanderWells-diamond AlexanderWells-diamond linked a pull request Oct 12, 2022 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Protect against overflow/underflow for integer record types DiamondLightSource/pythonSoftIOC
2 participants
@Araneidae @AlexanderWells-diamond