diff options
author | Szabolcs Nagy <nsz@port70.net> | 2018-12-01 23:52:34 +0000 |
---|---|---|
committer | Rich Felker <dalias@aerifal.cx> | 2019-04-17 13:07:29 -0400 |
commit | fe54544f055959bb7406758881d0fb85920b3f0e (patch) | |
tree | 0dc160a0a208919a10b6b09f204447b4887ce288 /src/math/__math_invalidf.c | |
parent | b50d315fd23f0fbc4c11e2583801dd123d933745 (diff) | |
download | musl-fe54544f055959bb7406758881d0fb85920b3f0e.tar.gz musl-fe54544f055959bb7406758881d0fb85920b3f0e.tar.bz2 musl-fe54544f055959bb7406758881d0fb85920b3f0e.tar.xz musl-fe54544f055959bb7406758881d0fb85920b3f0e.zip |
math: add eval_as_float and eval_as_double
Previously type casts or assignments were used for handling excess
precision, which assumed standard C99 semantics, but since it's a
rarely needed obscure detail, it's better to use explicit helper
functions to document where we rely on this. It also helps if the
code is used outside of the libc in non-C99 compilation mode: with the
default excess precision handling of gcc, explicit inline asm barriers
are needed for narrowing on FLT_EVAL_METHOD!=0 targets.
I plan to use this in new code with the existing style that uses
double_t and float_t as much as possible.
One ugliness is that it is required for almost every return statement
since that does not drop excess precision (the standard changed this
in C11 annex F, but that does not help in non-standard compilation
modes or with old compilers).
Diffstat (limited to 'src/math/__math_invalidf.c')
0 files changed, 0 insertions, 0 deletions