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.3not the normal libc result of 3.1e4bf14 (cores: replace max and min macros with imports from std #1783) replaced similar
min,maxmacros 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.