added CMake option USE_BOOST_INT128 to use a Boost.Multiprecision 128-bit integer for MathLib:big{u}int

[firewave]

No description provided.

[firewave]

Utilizing this to have actual 128-bit support is a long way off.

As a first step this allows to iron out the inconsistent usage of the Mathlib types ({unsigned }long long instead of big{u}int) because the 128-bit types are actual types and not an alias so incompatible conversions will cause compilation failures. The first round of fixes without any impact will be in a follow-up PR.

Even if we cannot make it work in the end this would still provide a way for strong type safety we can leverage in the CI.

[danmar]

As a complement.. if boost is not available and we compile cppcheck with gcc we could use __int128_t for bigints. However __int128_t does not support some math operations as far as I remember :-(

I am not sure if a 128-bit bigint is needed. At least not if our goal is only to handle all the 64-bit integers properly. Yes it is unfortunate to use "long long".
I believe that in clang/gcc they don't use a plain integer type to represent integer values like we do.

[danmar]

The first round of fixes without any impact will be in a follow-up PR.
Even if we cannot make it work in the end this would still provide a way for strong type safety we can leverage in the CI.

ok that sounds good 👍

[firewave]

As a complement.. if boost is not available and we compile cppcheck with gcc we could use __int128_t for bigints. However __int128_t does not support some math operations as far as I remember :-(

And Visual Studio has not 128-bit support (yet).

I am not sure if a 128-bit bigint is needed. At least not if our goal is only to handle all the 64-bit integers properly. Yes it is unfortunate to use "long long".

It is - see https://trac.cppcheck.net/ticket/9994. And this was looked into a few years ago already: #3430.

[danmar]

It is - see https://trac.cppcheck.net/ticket/9994.

I suggested here to use a class:
#3430 (comment)
that would be able to handle the value in 9994 properly because that is a 64-bit value.

The 128-bit integer has problems also. It won't automatically sign extend a signed 8-bit value properly or truncate 16-bit values properly. etc...

[firewave]

As mentioned above I am not yet looking into getting this working but start with the type safety as a baseline. If that is a given we essentially can replace it with anything - even dropping the whole boost build dependency. That should probably also help with identifying test cases (and possibly existing subtle issues).

[firewave]

Moved to the top so the default values for the options will be applied here.

[firewave]

I moved this because it will later be needed higher up in the class.