fixed some compiler errors with USE_BOOST_INT128

[firewave]

No description provided.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[chrchr-github]

What's the status of USE_BOOST_INT128? Maybe we should build it in the CI.

[firewave]

What's the status of USE_BOOST_INT128?

Getting quite close. ValueFlow::getSizeOf() needs to be sorted out. But the biggest blocker is arithmetic which is not supported by the type and I am not totally sure how to handle that. An intermediate solution I had in mind was to cast it to long long and give a debug message when it is out of range (I assume that will give some of the warnings we would also get if we enable -fsanitize=integer - and probably will spark controversy - again).

Maybe we should build it in the CI.

That's the plan when it fully builds.

[chrchr-github]

What's the status of USE_BOOST_INT128?

Getting quite close. ValueFlow::getSizeOf() needs to be sorted out. But the biggest blocker is arithmetic which is not supported by the type and I am not totally sure how to handle that.

Why would there be no arithmetic? This looks like at least the common operations are supported:
https://www.boost.org/doc/libs/1_87_0/libs/multiprecision/doc/html/boost_multiprecision/tut/ints/cpp_int.html

[firewave]

arithmetic which is not supported by the type

<<, ^, & et al. And then there's calls to math.h functions.

[firewave]

FYI

Using __int128 it already compiles and only lacks the string conversion of actual 128-bit values. I will prepare a PR so that can already be used.

Getting that much further uncovered issues with MathLib::calculate() and friends with unsigned values (i.e. greater than LLONG_MAX since it only provides signed results.

I will file appropriate tickets within the next days.