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

Safe numerics #125

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
Open

Safe numerics #125

wants to merge 5 commits into from

Conversation

tcbrindle
Copy link
Owner

This PR does a whole lot of things.

Firstly, we define some concepts for integers. Specifically, the flux::num::integral concept is satisfied by any std::integral type except bool, char, wchar_t and the various charN_ts. We also have corresponding signed_integral and unsigned_integral concepts.

Next, we define some functions which perform unchecked integer operations, namely:

  • unchecked_add
  • unchecked_sub
  • unchecked_mul
  • unchecked_div
  • unchecked_mod

These work call the built-in operators (and so can cause UB for signed types), but require both arguments to be the same type, and cast the result back to their argument type -- that is, there is no promotion, so unchecked_add(short, short) returns a short, not an int. The intention is that these can be used in places where signed UB can allow extra optimisations, and explicitly acknowledge that you're doing something dangerous.

Next is a set of wrapping functions:

  • wrapping_add
  • wrapping_sub
  • wrapping_mul

These work by casting their arguments to an unsigned type, performing the operation, and casting back to the starting type. They never cause UB, and can be used to specifically document that you want wrapping semantics.

Next is a set of functions which check whether overflow occurred:

  • overflowing_add
  • overflowing_sub
  • overflowing_mul

These return a (T, bool) pair which safely performs the operation (as if by wrapping) and reports whether overflow occurred. They use compiler builtins in GCC and Clang. These work for unsigned types as well as signed types, so you can test whether your size_t overflowed.

Then we have a set of checked arithmetic functions:

  • checked_add
  • checked_sub
  • checked_mul
  • checked_div
  • checked_mod

These raise a flux::runtime_error if overflow occurs (or division by zero for the last two functions), regardless of the compiled checking policy.

Finally, we have

  • add
  • sub
  • mul
  • div
  • mod

These perform overflow/divide-by-zero checks according to the configured policies. By default, they trap on overflow in debug mode or wrap in release mode.

Phew!

...in the <flux/core/numeric.hpp> header
This PR does a whole lot of things.

Firstly, we define some concepts for integers. Specifically, the `flux::num::integral` concept is satisfied by any `std::integral` type *except* `bool`, `char`, `wchar_t` and the various `charN_t`s. We also have corresponding `signed_integral` and `unsigned_integral` concepts.

Next, we define some functions which perform *unchecked* integer operations, namely:

 * `unchecked_add`
 * `unchecked_sub`
 * `unchecked_mul`
 * `unchecked_div`
 * `unchecked_mod`

These work call the built-in operators (and so can cause UB for signed types), but require both arguments to be the same type, and cast the result back to their argument type -- that is, there is no promotion, so `unchecked_add(short, short)` returns a `short`, not an `int`. The intention is that these can be used in places where signed UB can allow extra optimisations, and explicitly acknowledge that you're doing something dangerous.

Next is a set of wrapping functions:

* `wrapping_add`
* `wrapping_sub`
* `wrapping_mul`

These work by casting their arguments to an unsigned type, performing the operation, and casting back to the starting type. They never cause UB, and can be used to specifically document that you want wrapping semantics.

Next is a set of functions which check whether overflow occurred:

 * `overflowing_add`
 * `overflowing_sub`
 * `overflowing_mul`

These return a `(T, bool)` pair which safely performs the operation (as if by wrapping) and reports whether overflow occurred. They use compiler builtins in GCC and Clang. These work for unsigned types as well as signed types, so you can test whether your size_t overflowed.

Then we have a set of checked arithmetic functions:

* `checked_add`
* `checked_sub`
* `checked_mul`
* `checked_div`
* `checked_mod`

These raise a `flux::runtime_error` if overflow occurs (or division by zero for the last two functions), regardless of the compiled checking policy.

Finally, we have

* `add`
* `sub`
* `mul`
* `div`
* `mod`

These perform overflow/divide-by-zero checks according to the configured policies. By default, they trap on overflow in debug mode or wrap in release mode.

Phew!
@codecov
Copy link

codecov bot commented Aug 30, 2023

This adds
 * num::unchecked_shl
 * num::unchecked_shr
 * num::checked_shl
 * num::checked_shr
 * num::shl
 * num::shr

Which perform left and right bitshift operations either explicitly without undefined behaviour checking, or which check whether the shift amount is out of bounds
I got them the wrong way round
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

Successfully merging this pull request may close these issues.

None yet

1 participant