No protection against overflow/underflow when setting values

[AlexanderWells-diamond]

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]

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]

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

[Araneidae]

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]

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]

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.