]> granicus.if.org Git - jq/commit
Bugfix: Math function checking
authorAlex Ozdemir <aozdemir@hmc.edu>
Thu, 2 Aug 2018 07:25:07 +0000 (00:25 -0700)
committerWilliam Langford <wlangfor@gmail.com>
Fri, 12 Oct 2018 20:23:09 +0000 (16:23 -0400)
commit0c845aa291230cace495d06ac5465bd3ccb99319
tree4ec04c81bca4d7f58016f2518d038e16f06c3d78
parent341a5fcab34a19e155810e281e550f17d17b809f
Bugfix: Math function checking

We had config machinery that determined which math functions are
available in libc. If a c math function was missing on the host system,
then the corresponding jq function would be removed from the source,
enabling the build to proceed anyway. The detection machinery was broken
in a subtle way, as was shown after glibc updated to 2.27, dropping the
`pow10` function. This caused compilation to fail.

The essential problem was that we detected whether a math function was
available by compiling and linking a small program evaluating that
function on constants. However, since gcc's optimization machinery has
special knowledge of some math functions (e.g. `pow10`), it can
optimize them away, even if they don't exist in the library and are not
linkable. That is, the following example compiles and links against
glibc 2.27, even though `pow10` has been removed:
```
int main () {
  printf("%f", pow10(0.5));
  return 0;
}
```

What?!
On the other hand, this program does not link:
```

int main () {
  double f;
  printf("%f", &f);
  printf("%f", pow10(f));
  return 0;
}
```

In the first program the call to `pow10` can be optimized away as a
constant expression. This requires GCC to know about `pow10` (which it
does!), but it does not require `pow10` to be in the library (and
actually linkable).

The solution is to use autoconf's machinery for detecting function
presence, instead of our own (buggy) machinery. This has the added
benefit of simplifying the code.

The bug was reported in issue #1659
config/m4/check-math-func.m4
configure.ac