Silent cast errors

[merkste]

Currently, integer overflows and underflows are silent errors during expression evaluation. This may lead to models that are broken without a chance for the author to recognise the error.

This PR addresses issue #92 and consists of two parts:

1. Throw an error if a double cannot be casted to int
   Two classes are touched that cast the result of some prism functions and operators to int values. There might be more but non-obvious places where this happens. The commit also gets rid of unnecessary manual boxing and outmost scope variable declarations in the touched code.

2. Change error message for PrismLangExceptions
   This part allows to see the line and column numbers if a PrismLangException is raised, e.g., on cast errors.

[merkste]

To be clear: This change does affect the checkExpression and StateValues methods as they should™ not be relevant in model construction. It remains to discuss whether the problem should be addressed there as well by a separate PR.

[kleinj]

Hi @merkste,

thanks for the PR. I've split up and tweaked the commits a bit so that the unboxing changes are in a seperate commit (for performance testing) and added overflow-aware handling for the unary minus as well; those are pushed to master. I did some cursory performance testing by building models from the prism-benchmark suite; the boxing stuff seems to have a minor positive impact, the overflow-aware math a minor negative impact (as always depending on the particular model). Overall it seems to be reasonable to include for the benefit of better checking.

For the "Change error message for PrismLangExceptions" commit, I had a look and did not see how the change has an effect, the toString() call in PrismLangException just calls getMessage() as well, so the line number etc should appear with the current code as well?

I've also started writing test cases for these integer overflows, however currently the prism-auto-based test suite lacks a mechanism for forcing a specific engine for a test case (i.e., to ignore those test cases for engines other than 'explicit') when running with extra arguments.

As you mentioned the checkExpression and StateValues integer operations, for those there is a design decision what to do if an overflow error happens in those parts of the state space that are not actually relevant (i.e., not covered by the statesOfInterest). In principle, the values there could be arbitrarily broken. Unfortunately, there does not seem a smart way to have something similar to NaN for ints...

[merkste]

@kleinj @davexparker : As far as i can see, this PR (expect for the PrismLangException part) is integrated in the commits

• f1b70b6
• dba1c01
• 2ecfe7a
• 917dd5e

Is this correct? If yes, I suggest to close the PR.