Use std::abs for a float-compatible abs() function #2738
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Other Arduino cores uses a macro to redefine libc abs() to take any type, meaning
abs(-3.3) == 3.3
not the normal libc result of 3.1e4bf14 (cores: replace max and min macros with imports from std #1783) replaced similar
min
,max
macros with c++ stdlib. However this change includes<algorithm>
after the line which defines the abs() macro.<algorithm>
includes<cstdlib>
which undefinesabs()
and re-defines it.As a result, current esp32 Arduino core has a bug compared to other Arduino cores:
abs()
is now the plain libc version which only takes integers, soabs(-3.3) == 3
. As reported here: float computations (fp32, fp64) evaluate differently vs. ARM Cortex M0+M3+M4 & Mega2560 (IDFGH-1084) esp-idf#3405This fix tries to keep in the spirit of #1783 by using libstdc++ rather than a macro, for the same effect (abs can take any compatible type). The other option would be to include
<cstdlib>
before defining theabs()
macro, so it doesn't get undef-ed again later on.This will probably also fix #2128 as the
abs()
macro is no longer defined.