rtapi: define the math constants that are missing in kernel space - #4395
Open
grandixximo wants to merge 1 commit into
Open
rtapi: define the math constants that are missing in kernel space#4395grandixximo wants to merge 1 commit into
grandixximo wants to merge 1 commit into
Conversation
The math constants are not in ISO C. Userspace takes them from math.h; a kernel build takes the other branch of this header, which includes no math.h, so the header already defines M_PI, M_PIl and M_PI_2l when they are absent. The other twelve of glibc's set are absent in kernel space, so using one in real time code builds on uspace and fails on RTAI. Define them under the same guard, with the values glibc uses. M_PI itself was spelled with the long double digits truncated; it rounds to the same double, but write it as glibc does. The typed variants are left out apart from the two already here.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Follows from the review discussion in #4387, on whether posemath's PM_PI and friends should just be the libc constants.
The math constants are not in ISO C. Userspace gets them from math.h, where glibc keeps the long double spellings behind _GNU_SOURCE, and a kernel build takes the other branch of rtapi_math.h, which includes no math.h at all. The header already fills in M_PI, M_PIl and M_PI_2l for that case, which are the three the tree happens to use.
The other twelve of glibc's set are absent in kernel space, M_PI_2 and M_PI_4 among them, so real time code using one builds on uspace and fails on RTAI. Nothing in tree uses them today, which is the only reason it has never shown. This defines them under the same #ifndef guard with glibc's values, and rewrites M_PI's literal, which was the long double spelling truncated, the way glibc writes it.
The typed variants, the f, f32, f64, f128 and l suffixes, are left out apart from the two already there.
Testing.
Preprocessing rtapi_math.h down both branches: kernel space goes from 3 names to the same 15 userspace has. Each of the 15 compares equal to the glibc value in its own type, the two long double ones included, so the truncated digits were cosmetic rather than a difference in value.
Including math.h before or after rtapi_math.h is clean under -Wall -Wextra -Werror in both orders, so the guards do not fight libc either way round.
Full build clean, no errors and no warnings. runtests over blendmath, realtime-math and interp: 84 run, 84 successful, 0 failed, 1 skipped.
One to remember when the PM_ names map across: M_2_PI is 2/pi in libm, not 2pi, so PM_2_PI becomes 2M_PI.