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.

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

bad_numeric_cast exception: review code changes and spec #191

Open
mhier opened this issue Nov 3, 2020 · 2 comments
Open

bad_numeric_cast exception: review code changes and spec #191

mhier opened this issue Nov 3, 2020 · 2 comments
Assignees

Comments

@mhier
Copy link
Member

mhier commented Nov 3, 2020

Review the following commits:

They are somewhat contradicting the TransferElement spec C.4 (in particular 4.3) which still mentions the bad_numeric_cast exceptions. This part of the spec (and all other references to this exception) shall be reviewed as well. It should be decided which of the following solutions shall be implemented:

  • overflows always result in the closest possible value
  • asymmetric behaviour: in writes, overflows always result in the closest value, while for reading overflows are prevented in the constructor phase (logic_error if type is too small).

The second solution raises the question how to handle (as an extreme example) bidirectional variables between ApplicationModules involving a conversion (which is currently not implemented, but maybe it should be in future?).

@killenb
Copy link
Member

killenb commented Nov 5, 2020

A discussion with @mhier lead to the conclusion that symmetric behaviour is the better solution.

  • Overflows result in the closest possible value AND the data validity flag is set to faulty.
    This holds for both directions. An implementation (like PCIe) might ignore it / not transport it when writing.
  • Overflows in a single element of an array result in the maximum/minimum representable value only in that element. The data validity flag, which is for the whole process variable, is set to faulty.

@killenb killenb self-assigned this Nov 5, 2020
@killenb
Copy link
Member

killenb commented Nov 5, 2020

I reviewed the code changes. They are fine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants