issue #241: add infrastructure for range checking#296
Conversation
|
@tbeu I still need to fill out all the variants of the conversion functions, but any thoughts on this general approach? |
|
CI is failing. This needs to be addressed. |
That's expected. This is WIP. I'd like to know if you find the general approach acceptable before I spend more time to finish it off. |
|
So well, if it works and solves the issue... |
OK I'll finish it off then... |
8726eab to
2c6094d
Compare
|
@tbeu ok I've decided to split this into 2 PRs since there's 1 test failing that needs investigation. So for now, this first PR only adds the the infrastructure to eventually fix the UB conversions. It should change no behaviour. It's ready for review and merging. |
Hmmm, Is this an old compiler? Or one that doesn't support C very well? Maybe it does not like |
|
Some searching suggests indeed MS compilers don't support C well, and might not like |
| #define READ_TYPE_UINT64_DATA CAT(READ_TYPED_FUNC1, UInt64) | ||
| #endif /* HAVE_MAT_UINT64_T */ | ||
|
|
||
| // Converts value from its own type to READ_TYPE, carefully ensuring the value fits, otherwise sets success to false. |
There was a problem hiding this comment.
| // Converts value from its own type to READ_TYPE, carefully ensuring the value fits, otherwise sets success to false. | |
| // Stubs only: Converts value from its own type to READ_TYPE. |
There was a problem hiding this comment.
OK, done. Indeed that comment is not yet true, but it will be in the next PR.
Modified READ_DATA macro to: - know both source and destination type - provide a function to convert between types For now the conversion function just casts, which is what the macro did before. In other words, this commit should not change any behaviour at all. It only adds infrastructure. Subsequently we can carefully implement the conversion functions to not invoke undefined behaviour when converting, for example, large ints to small ints.
for more information, see https://pre-commit.ci
No description provided.