======================================================================== * README ======================================================================== Copyright 2000-2020 Free Software Foundation, Inc. Contributed by the AriC and Caramba projects, INRIA. This file is part of the GNU MPFR Library. The GNU MPFR Library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version. The GNU MPFR Library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with the GNU MPFR Library; see the file COPYING.LESSER. If not, see https://www.gnu.org/licenses/ or write to the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA. ############################################################################## The GNU MPFR distribution contains the following files: (This does not apply to code retrieved by Subversion.) AUTHORS - the authors of the library BUGS - bugs in MPFR - please read this file! COPYING - the GNU General Public License, version 3 COPYING.LESSER - the GNU Lesser General Public License, version 3 ChangeLog - the log of changes INSTALL - how to install MPFR (see also mpfr.texi) Makefile* - files for building the library NEWS - new features with respect to previous versions PATCHES - empty file (until patches are applied) README - this file TODO - what remains to do (any help is welcome!) VERSION - version of MPFR (next release version if taken by Subversion) ac*.m4 - automatic configuration files ar-lib - auxiliary installation file compile - auxiliary installation file config.* - auxiliary installation files configure* - configuration files depcomp - auxiliary installation file doc/ - directory containing documentation (manual, FAQ, etc.) examples/ - directory containing examples install-sh - installation file ltmain.sh - auxiliary installation file m4/ - directory containing additional configuration files missing - auxiliary installation file mpfr.pc.in - auxiliary pkg-config file src/ - directory containing the MPFR source test-driver - auxiliary installation file tests/ - directory containing the testsuite (for "make check") tools/ - directory containing various tools tune/ - directory containing files for tuning MPFR According to the special exception to the GNU General Public License, the autotools files compile, config.sub, config.guess, ltmain.sh, m4/libtool.m4 and missing are distributed under the same licence of GNU MPFR. For any copyright year range specified as YYYY-ZZZZ in this package, note that the range specifies every single year in that closed interval. Official GNU MPFR website: https://www.mpfr.org/ NOTE: At the time of the release 4.1.0, the MPFR repository is hosted at InriaForge, but it will need to migrate since InriaForge will shut down in December 2020. Please go to https://www.mpfr.org/ for the current status. What follows remains valid until the migration is done. You can get the latest source code by Subversion at InriaForge: svn checkout svn://scm.gforge.inria.fr/svn/mpfr/trunk mpfr or svn checkout https://scm.gforge.inria.fr/svn/mpfr/trunk mpfr (the last argument can be any directory name). You can use svn ls svn://scm.gforge.inria.fr/svn/mpfr/branches svn ls svn://scm.gforge.inria.fr/svn/mpfr/tags to get the list of branches or tags (releases), then checkout a particular branch or tag instead of the trunk. Alternatively, you can now use the "https:" scheme (a.k.a. DAV) instead of "svn:". For more information about Subversion, please see: * http://svnbook.red-bean.com/ (the official Subversion book); * https://gcc.gnu.org/wiki/SvnHelp (written for GCC developers, but interesting general information can be found there); * http://subversion.apache.org/faq.html (the Subversion FAQ). Subversion users should read the file "doc/README.dev" (in the source tree). ======================================================================== * doc/README.dev ======================================================================== Copyright 2002-2020 Free Software Foundation, Inc. Contributed by the AriC and Caramba projects, INRIA. This file is part of the GNU MPFR Library. The GNU MPFR Library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version. The GNU MPFR Library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with the GNU MPFR Library; see the file COPYING.LESSER. If not, see https://www.gnu.org/licenses/ or write to the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA. Notes for the MPFR developers and Subversion users ================================================== To compile source code obtained from the Subversion repository, you need some GNU development utilities: aclocal, autoheader, automake, autoconf 2.60 (at least), libtoolize, and the AX_PTHREAD macro from (for the latter, under Debian/Ubuntu it suffices to install the autoconf-archive package). As some files like "configure" are not part of the Subversion repository, you first need to run "autoreconf -i" (or ./autogen.sh, which could be used later to update the config files). Then you can run ./configure in the usual way (see the INSTALL file, but note that there are no patches to apply, and the URLs are not valid since the corresponding version has not been released yet). To generate mpfr.info, you need texinfo version 4.2 (or higher). =========================================================================== The VERSION file contains the number of the next release version, i.e. the version currently being developed. A suffix can be attached for the development versions (in general, "-dev") or pre-release versions (e.g. "-rc1"). It must be updated with the update-version script. Examples: tools/update-version 3 1 0 dev tools/update-version 3 1 0 rc1 tools/update-version 3 1 0 The "-dev" suffix means that additional tests may be done or required for development. For instance, the data files from the tests/data directory are required; such files are not included in tarballs as they can be large. If nightly snapshots are built, the date in the yyyymmdd format and/or the Subversion revision number (giving more accurate information) must be added to the version as a suffix, for instance: "2.3.0-20070621" or "2.3.0-r4553". Patches can be tracked by adding a chunk of the form --- PATCHES~ Tue Nov 6 19:59:33 2001 +++ PATCHES Tue Nov 6 19:59:42 2001 @@ -1,0 +1 @@ + to the patch file[*]. After such patches have been applied, the file src/get_patches.c providing the mpfr_get_patches() function will be rebuilt by "make". MPFR distributors can still modify the version suffix from the applied patches according to their version naming scheme; for instance, for their own patches, MPFR developers do: tools/update-version 3 1 0 p1 - [*] This idea comes from Thomas Roessler, who implemented it in Mutt. For patches from MPFR developers, e.g. for MPFR 3.1.0: 1. Unarchive the tarball: a directory mpfr-3.1.0 is created. 2. Go into this directory (cd mpfr-3.1.0). 3. Apply the current patches with "patch -N -Z -p1 < /path/to/allpatches". 4. Reset the PATCHES file with "true >| PATCHES". 5. Rename mpfr-3.1.0 as mpfr-3.1.0-a and duplicate it as mpfr-3.1.0-b without changing the timestamps (e.g. with cp -a). 6. In mpfr-3.1.0-b, apply the patch obtained with "svn diff", e.g. patch --no-backup-if-mismatch -p0 < /path/to/new_patch If an autotools file has been modified, run "autoreconf" and remove the autom4te.cache directory. 7. In mpfr-3.1.0-b, update the version information: tools/update-version 3 1 0 p - where is the patch number. 8. In mpfr-3.1.0-b, update PATCHES file: echo >> PATCHES 9. Make the patch: TZ=UTC0 diff -Naurd mpfr-3.1.0-a mpfr-3.1.0-b The tools/build-patch script can be used to ease the process. Note: if autotools files are modified, the corresponding changes in the distributed files depending on them must be included in the patch, and the timestamps of such autotools files should be reset so that they do not change when the patch is applied with the -Z option. Otherwise the autotools would be needed to build MPFR (unless maintainer mode is disabled). Patches are put under the misc/www directory of the Subversion repository. The web server is updated and patches are also copied as InriaForge files. =========================================================================== When submitting patches, unified diffs (option -u) are recommended, as they are more readable. You can also use the option -d to generate a smaller set of changes. See diff(1) for more information. =========================================================================== Copyright Notices: For easier maintainability, make sure that the copyright notices match the regexp "Copyright.* yyyy Free Software" where yyyy is the year of the latest modification in the branch (and nothing else should match it). The latest rules for GNU software can be found here: https://www.gnu.org/prep/maintain/maintain.html#Copyright-Notices =========================================================================== To make a release (for the MPFR team): *** Please read this section entirely before making any release. *** 0) For a non-patchlevel release, before creating a branch from the trunk (or more often), some operations should be done: * make sure that the src/mpfr-longlong.h file (from GMP's longlong.h) is up-to-date (updates could also be done in patchlevel releases, but with care); * among the checks below, those that are most likely to notice issues, as it is easy to forget something; * in particular, check that the abi-compliance-checker output, the "API Compatibility" section of the manual (mpfr.texi), and the NEWS file are consistent; * update the libtool version (see src/Makefile.am) and the DLL version (see configure.ac) if need be, though this should have been done as soon as the ABI changed in the trunk; * update the ChangeLog (see below) in the trunk, in order to minimize the future diffs. If everything is OK, create the branch. Then: 1) Check the version and change the suffix to "rc1", "rc2", etc. with tools/update-version for the release candidates; remove the suffix for the final release. Update the libtool version (see src/Makefile.am), needed at least for patchlevel releases. Update the DLL version (see configure.ac) if not done yet. Check these versions with tools/ck-version-info (this check will also be done automatically by "make dist" / "make distcheck"). Update the date in doc/mpfr.texi. 2) Generate the tuning parameters on different architectures and put them in src/mparam_h.in. For each architecture: a) download the latest release of GMP on gmplib.org b) build GMP with --disable-shared in say /tmp/gmp-x.y.z There is no need in tuning GMP, since most users will build MPFR with a vanilla GMP installation, i.e., with the default GMP tuning; however you need to go into /tmp/gmp-x.y.z/tune and type "make speed" (the MPFR tuning is using the resulting speed library) c) configure MPFR with --disable-shared --with-gmp-build=/tmp/gmp-x.y.z d) go into the "tune" directory and run "make tune" e) put the resulting mparam.h file into mparam_h.in (please include the version of GMP and the compiler used) You can produce time graphs to check the thresholds are correct (and compare to the corresponding mpf functions) with mbench. For example (-x1 corresponds to add, -x2 to sub, -x3 to mul, ...): $ cd mpfr/tools/mbench $ make mpfr-gfx GMP=... MPFR=... $ ./mpfr-gfx -b16 -e320 -s16 -f2 -x3 # compares mpfr_mul and mpf_mul # from 16 to 320 bits with increment # of 16 bits $ gnuplot -persist plot.gnuplot Another example, comparing mpfr_mul and mpf_mul from 2 to 1000000 bits, with ratio 1.1 between two sizes, 10 random values, and 10 smoothness checks: $ ./mpfr-gfx -b2 -e1000000 -r1.1 -f10 -x3 -m10 $ gnuplot -persist plot.gnuplot Check the coverage of each source file by the test suite is at least 90% (or clearly justify any value under this threshold), and publish (for example in NEWS) the global coverage of this release. The individual coverage of each source file might also be published on the release web page. There is a specific mparam.h file to improve coverage; it should be tested by configuring MPFR with -DMPFR_TUNE_COVERAGE. Also test with -DMPFR_COV_CHECK, which allows one to check the coverage of some combinations of variable values (as defined in the MPFR source and test suite). 3) Update the NEWS file, in particular say if the release is binary and/or API compatible (or not) with previous releases. Also update the "API Compatibility" section in the manual (mpfr.texi). Check with abi-compliance-checker (ABI Compliance Checker)[*], on the latest MPFR releases built with no configure options (except --prefix), that no changes have been missed. The ^/misc/build-multi script in the repository may be useful to prepare data for abi-compliance-checker. Note that abi-compliance-checker can only check the symbols, types and constants; it cannot detect just a change in the behavior, thus may miss some incompatibilities. Update the FAQ.html file with update-faq (and check it) in the doc directory. [*] https://lvc.github.io/abi-compliance-checker/ 4) Update the ChangeLog file with "TZ=UTC0 svn log -rHEAD:0 -v" in UTF-8 locales, e.g. "LC_ALL=en_US.UTF8 TZ=UTC0 svn log -rHEAD:0 -v". This should at least be done last, in order to be complete before the generation of the tarball. Note: First, make sure that all the pending commits have been done. 5) Do a "svn export" of the branch to make sure to start from a clean source tree; this also has the advantage (over a checkout) to set the timestamps to the commit time, ensuring the right ordering of the files by date. Generate the tarballs with: $ ./autogen.sh $ ./configure $ make distcheck 6) Test the release version on different machines, with --enable-assert set to "yes", "no" (default), "none" and "full" respectively, with and without -DMPFR_DISABLE_IEEE_FLOATS in $CFLAGS, with and without gmp internal files (--enable-gmp-internals), with and without GMP built as a shared library, with objdir equal to and different from srcdir (e.g. ../mpfr-source/configure after making mpfr-source read-only), with and without --enable-logging. Try different temporary allocation methods: GMP's --disable-alloca configure option (or compile GMP with --enable-alloca=debug and MPFR with --with-gmp-build to be able to get the memory leak errors); and -DMPFR_ALLOCA_MAX=0. Try different gcc versions with different options: with and without "-std=c99 -O3 -D_XOPEN_SOURCE=500", with and without "-ansi" (which allows to turn off features that are incompatible with ISO C90), with and without [-ansi] -pedantic-errors (which has the effect to disable extensions, such as long long when used together with -ansi), with and without -std=c11, with and without --enable-thread-safe, in various FPU precisions (double, double extended and single) if the platform supports that (e.g. under Linux/x86, with GCC and its -mpc64 option to simulate the FreeBSD / NetBSD 6- behavior, where by default, the x87 FPU is configured to round on 53 bits), and in various locales (LC_ALL=tr_TR in particular, if installed). On x86, test with -m96bit-long-double and -m128bit-long-double. Try also with gcc's -fno-common option. Check also with "-Wformat=2", but without logging support (in order to avoid too many spurious warnings). Check with "-UHAVE_BIG_ENDIAN -UHAVE_LITTLE_ENDIAN" to simulate platforms where the endianness is unknown (or can't be specified without AC_CONFIG_HEADERS). Check also without the mpz_t pool (-DMPFR_POOL_NENTRIES=0). Check the generic code, e.g. with -DMPFR_GENERIC_ABI in $CFLAGS (useful because most tests are written for low precision) and with mpfr_cv_c_long_double_format=unknown (as a variable assignment). Check with -DMPFR_GROUP_STATIC_SIZE=0 to detect memory leaks that would occur in medium precision or more if a MPFR_GROUP_CLEAR were forgotten. Check that make and make check pass with a C++ compiler, for example: ./configure CC=g++ (MPFR 2.3.2 did not). Also test --enable-gmp-internals with it. Try different compilers, e.g., icc, opencc (x86_64 machines), tcc , llvm-gcc, clang. On 64-bit PowerPC, test against GMP built with the different ABI's: 32, mode32 and mode64 (in particular mode32, where long's have 32 bits and limbs have 64 bits [long long]). Test with -DMPFR_TESTS_FPE_DIV -DMPFR_ERRDIVZERO -DMPFR_DISABLE_IEEE_FLOATS in order to detect whether tests can fail due to a FP division by 0 (yielding either FE_DIVBYZERO, e.g. from 1.0 / 0.0 to generate an infinity, or FE_INVALID, e.g. from 0.0 / 0.0 to generate a NaN) on platforms where such an operation fails (e.g. trap). On platforms that do not support IEEE 754, such an operation yields an undefined behavior. If _MPFR_IEEE_FLOATS is defined to 1 (by the configure script), some divisions by 0 are avoided in the MPFR library. The -DMPFR_DISABLE_IEEE_FLOATS option sets _MPFR_IEEE_FLOATS to 0, allowing one to detect more issues, for platforms without IEEE floats. Test with -D_MPFR_PREC_FORMAT=2 when the "int" type is smaller than the "long" type. Test with mini-gmp. Test with valgrind by setting the environment variable: LOG_COMPILER="valgrind -q --error-exitcode=1 --leak-check=full" See below for more information about valgrind. Test with "clang -fsanitize=undefined" (available as of Clang 3.3), e.g.: ./configure CC=clang CFLAGS='-fsanitize=undefined' The -fno-sanitize-recover option can give more visibility by making the corresponding tests fail (useful for automated tests). However clang unconditionally regards the floating-point division by zero as an error with "-fsanitize=undefined"; this is detected by a configure test, which sets MPFR_ERRDIVZERO to disable the tests involving a floating-point division by zero. Alternatively, on systems supporting IEC 60559 / IEEE 754 division by zero, one can also provide the -fno-sanitize=float-cast-overflow,float-divide-by-zero option *after* the -fsanitize=undefined one. GCC 4.9 also supports "-fsanitize=undefined", but it just gives diagnostic messages at run time, not a failure; GCC 5 supports -fno-sanitize-recover like clang. Test with GCC's AddressSanitizer (-fsanitize=address). Optimizations should not be enabled, otherwise they can make some errors disappear. One also needs to unset LD_PRELOAD or use -static-libasan to avoid failures. But the -static-libasan solution does not work with MPFR, as it yields the following error: Your application is linked against incompatible ASan runtimes. Test with i686-w64-mingw32 under Wine (see below). Test with both "make check" and the worst cases. Check various warnings, in particular for obsolescent features. With GCC: "-Wall -Wold-style-declaration -Wold-style-definition -Wmissing-parameter-type -Wmissing-prototypes -Wmissing-declarations -Wmissing-field-initializers". The -Wint-in-bool-context option could be added once available. These warnings can easily be checked in automatic tests by adding "-Werror -Wno-error=unused-function", but this needs: * GCC 4.9+ * a patched autoconf: https://lists.gnu.org/archive/html/autoconf-patches/2014-01/msg00003.html Check whether some functions could be declared as pure, const, etc. with GCC, using -Wsuggest-attribute=... options. Check that there are no abnormal regressions in the timings (both for 100, 1000, 10000 digits, https://www.mpfr.org/mpfr-current/timings.html, and for small precision, using the mbench program, see mpfr/mbench). Test the library interface compatibility by running the test suite compiled against an old library version and dynamically linked with the new library version: for instance, build the shared library of old and new MPFR versions with the same configure options, and from the build directory of the old version, do something like: (cd src/.libs && \ ln -nsf ../../../mpfr-new/src/.libs/libmpfr.so.1.* libmpfr.so.1) then "make check". Also test with different environment variables set (GMP_CHECK_RANDOMIZE, MPFR_CHECK_LIBC_PRINTF, MPFR_CHECK_LARGEMEM, MPFR_CHECK_EXPENSIVE, MPFR_SUSPICIOUS_OVERFLOW, MPFR_CHECK_LOCALES, MPFR_CHECK_BADCASES). Check there is no branch misprediction due to wrong MPFR_LIKELY or MPFR_UNLIKELY statements. For that test, configure with --enable-debug-prediction, run "timings-mpfr 100", and check that the output contains no WARNING. For various platforms and compilers, check that: * [make check-gmp-symbols] MPFR does not use GMP internal symbols (unless --with-gmp-build or --enable-gmp-internals has been used); * [make check-exported-symbols] MPFR does not define symbols with a GMP reserved prefix. But note that these rules are not really portable: they may do nothing or might even incorrectly fail on some platforms. 7) For the release itself (not the release candidates), if no problems have been found, create a tag with: svn cp .../mpfr/branches/x.y .../mpfr/tags/x.y.z 8) For the release itself (not the release candidates), update the version with the update-version script to indicate the next version (use the "dev" suffix). 9) * For the release itself (not the release candidates): Create a web page for the MPFR release and add the documentation (for mpfr.html, use "makeinfo --html --no-split mpfr.texi" from the doc directory). Make sure that both the .dvi and .ps files have an a4 papersize (see technical information later about the MPFR manual). Upload the tarballs and the signatures to the MPFR web server (via a svn working copy) and to InriaForge. Prepare the files for the GNU FTP site with the gnu-sigdir script in the /misc directory and upload them. Update the mpfr-current symbolic link and the history page. Update the old current page to point to the new release; see examples for 3.0.1 (latest version of the branch) and 3.1.0 (which is not the latest version of the branch). Run the tools/announce-text script to do some checking and get the announce text. Edit this text if need be. Announce the release in the mpfr-announce, mpfr, gmp-discuss, gcc and info-gnu[1] mailing-lists, and on InriaForge (MPFR News, and contact the InriaForge administrators[2] to have the announce published on the main page). In case of a new patchlevel release, add a link from the web page of the previous release. * For the release candidates: Announce the RC in the mpfr-announce, mpfr, gmp-discuss, gcc and platform-testers[3] mailing-lists. A minimal web page for the MPFR release can be created right now (see svn history such as [4] for examples), as the manual already contains the new URL's. [1] https://www.gnu.org/prep/maintain/html_node/Announcements.html [2] http://siteadmin.gforge.inria.fr/FAQ.html [3] See https://lists.gnu.org/mailman/listinfo/platform-testers and https://lists.gnu.org/archive/html/platform-testers/2011-09/msg00000.html [4] https://gforge.inria.fr/scm/viewvc.php/misc/www/mpfr-3.1.2/index.html?view=markup&revision=8472&root=mpfr Note: Mail sent to the mpfr-announce list should also be sent to the mpfr list, and the Reply-To should be set to the mpfr list. For major or minor releases (but not patchlevels), a branch may be created first to allow new features to be committed to the trunk. To add tcc support with libtool 2.4.2 or below, do the following before running "make distcheck": $ patch m4/libtool.m4 libtool-tcc-wl.patch $ autoreconf And for libtool 2.4.3 to 2.4.6, the following is needed: $ patch m4/libtool.m4 libtool-tcc-rpath.patch $ autoreconf =========================================================================== Here is a non-exhaustive list of macros used for building and checking MPFR. Most of them are automatically set up by the configure script and its options. List of macros used for building MPFR (also used for checking): + HAVE_CONFIG_H: Define if we have to include 'config.h' first. + MPFR_HAVE_GMP_IMPL: Define if we have the gmp internal files. ('gmp-impl.h', 'gmp-maparam.h', ...). + MPFR_USE_MINI_GMP: Define to use mini-gmp. + HAVE_ALLOCA: Define if alloca() works. + HAVE_ALLOCA_H: Define if the function alloca() is in alloca.h. + HAVE_LOCALE_H: Define if is available. + HAVE_LONG_LONG: Define if the system supports 'long long'. + HAVE_STDARG: Define if the system supports 'stdarg.h'. Otherwise it is assumed it is 'vararg.h'. + HAVE_INTTYPES_H: Define if is available (ISO C99). + HAVE_STDINT_H: Define if is available (ISO C99). + MPFR_HAVE_INTMAX_MAX: Define if the INTMAX_MAX macro works correctly (if 'intmax_t' is supported). + MPFR_HAVE_C11_LOCK: Define if C11 threads are supported. + HAVE_PTHREAD: Define if pthread is available. Format of long double. + HAVE_LDOUBLE_IS_DOUBLE: IEEE double. + HAVE_LDOUBLE_IEEE_EXT_BIG: IEEE extended, big endian. + HAVE_LDOUBLE_IEEE_EXT_LITTLE: IEEE extended, little endian. + HAVE_LDOUBLE_IEEE_QUAD_BIG: IEEE quad, big endian. + HAVE_LDOUBLE_IEEE_QUAD_LITTLE: IEEE quad, little endian. + HAVE_LDOUBLE_MAYBE_DOUBLE_DOUBLE: Double-double (a.k.a. IBM). + MPFR_DISABLE_IEEE_FLOATS: Related to the native floating-point types (e.g. for conversion functions), use the generic code instead of IEEE 754 specific one. Note: This is mainly for developers in order to check the generic code, as machines without IEEE floating-point types are very uncommon nowadays. + MPFR_WANT_ASSERT: Assertion level. See src/mpfr-impl.h for details. + MPFR_EXP_CHECK: Define if we want to check the exp field. + _MPFR_PREC_FORMAT: Used to define the mpfr_prec_t type. + _MPFR_EXP_FORMAT: Used to define the mpfr_exp_t type. Note: these two macros are for internal use, testing and experimented users only; they must not be changed when the MPFR library is to be installed in a system directory. + IEEE_DBL_MANT_DIG: Number of bits in the significand (mantissa) of a double (default: 53). + MPFR_LDBL_MANT_DIG: Number of bits in the significand (mantissa) of a long double (generally based on the standard macro LDBL_MANT_DIG). Note: be careful with formats such as double-double (a.k.a. IBM long double). + MPFR_USE_LOGGING: Define to enable logging. + MPFR_WANT_DECIMAL_FLOATS: Define to build conversion functions from/to decimal floats. At most one of the following three macros can be defined. + DECIMAL_BID_FORMAT: BID encoding detected or assumed. + DECIMAL_DPD_FORMAT: DPD encoding detected or assumed. + DECIMAL_GENERIC_CODE: Use generic code for decimal floats. + MPFR_WANT_FLOAT128: Define to build conversion functions from/to binary128 floats (_Float128 or __float128). + MPFR_ALLOCA_MAX: Maximum size for the use of alloca() by temporary allocations (default: 16384); if set to 0, alloca() will not be used, and not even referenced. This macro is not used when MPFR is built with the GMP build directory (--with-gmp-build). + MPFR_USE_THREAD_SAFE: Define to build MPFR as thread safe (TLS). + MPFR_USE_C11_THREAD_SAFE: Define to implement TLS in the C11 way. + MPFR_WANT_SHARED_CACHE: Define to have caches shared by all threads. + MPFR_THREAD_LOCK_METHOD: When MPFR_WANT_SHARED_CACHE is defined, this macro gives the thread locking method (string). + MPFR_HAVE_NORETURN: Define if the _Noreturn function specifier is supported. + MPFR_HAVE_BUILTIN_UNREACHABLE: Define if the __builtin_unreachable GCC built-in is supported. + MPFR_GENERIC_ABI: Define to disable code that is tied to a specific ABI (e.g. GMP_NUMB_BITS value). Note: Currently it is also used to disable code specific to low precision, i.e. to use only generic code. This is useful because most tests are written for low precision, meaning that without this macro, the generic code would not sufficiently be tested. + MPFR_WANT_PROVEN_CODE: Define to enable formally proven code. List of macros used for checking MPFR: + MPFR_HAVE_FESETROUND: Define if the function fesetround() is available (and in header ). + MPFR_FPU_PREC: Allows to test MPFR on x86 processors when the x87 FPU rounding precision has been changed (see tests/tests.c for its usage). + HAVE_SUBNORM_DBL: Define if the double type fully supports subnormals. + HAVE_SUBNORM_FLT: Define if the float type fully supports subnormals. + HAVE_SIGNEDZ: Define if signed zeros are supported. + HAVE_SYS_TIME_H: Define if the header sys/time.h is usable. + HAVE_GETTIMEOFDAY: Define if the function gettimeofday() is available. + HAVE_SETLOCALE: Define if the function setlocale() is available. + MPFR_ERRDIVZERO: Define if the floating-point division by 0 fails in the MPFR library (e.g., because a SIGFPE signal is generated, or because it is regarded as undefined behavior by a sanitizer). This disables the tests involving such operations. Note: Tests related to NaN and infinities must not rely on native FP division by 0, whether this macro is defined or not. + MPFR_TESTS_FPE_DIV: Define to check whether there has been a FP exception FE_DIVBYZERO or FE_INVALID, which probably comes from 1.0 / 0.0 or 0.0 / 0.0 to generate an infinity or a NaN. This is normally used together with MPFR_ERRDIVZERO, in order to check that all divisions by 0 have been protected in the tests (so that tests can pass on platforms where the floating-point division by 0 fails). + MPFR_TESTS_FPE_TRAP: Define to trap the FE_DIVBYZERO and FE_INVALID exceptions; MPFR_TESTS_FPE_DIV needs to be defined too, and MPFR_ERRDIVZERO should be defined as well to avoid spurious traps (see above). + MPFR_TESTS_TIMEOUT: Define to enable timeout in the tests. Its value specifies the default timeout (in seconds), or 0 for no timeout by default. When defined, this value can be overridden at run time (e.g., with "make check" or when executing an individual test) with the MPFR_TESTS_TIMEOUT environment variable. + MPFR_TESTS_ABORT: Define to replace exit(1) by abort(), thus with a core dump. + MPFR_COV_CHECK: Define to enable value coverage checking (must not be used in production). This macro is for the MPFR developers, in order to improve the test suite. =========================================================================== Environment variables that affect the tests: + GMP_CHECK_RANDOMIZE: Seed for the random functions, except for 0 or 1, in which case a random (time based) seed is used. By default, a fixed seed is used. Only developers and testers should change the seed. + MPFR_CHECK_LARGEMEM: Define to enable tests that take a lot of memory. + MPFR_CHECK_EXPENSIVE: Define to enable tests that take a lot of time. Warning! The --enable-assert=full option should not be used, otherwise this can take much too long. While checking assertions (--enable-assert) may be useful with MPFR_CHECK_EXPENSIVE, the --enable-assert=full is not necessary with it. + MPFR_CHECK_LIBC_PRINTF: Define to enable comparisons with the printf function of the C library. These comparisons are disabled by default as failures could be due to the C library itself on some machines, and they do not affect MPFR. + MPFR_CHECK_LOCALES: Fail in case a locale cannot be set. Developers can set this variable on their machines to make sure that needed locales are properly installed and tested. + MPFR_CHECK_BADCASES: Fail if function bad_cases generates too many cases for which f(f^{-1}(x)) ≠ x, due to a poor choice of the parameters. + MPFR_DEBUG_BADCASES: For debugging (see tests.c, function bad_cases). + MPFR_SUSPICIOUS_OVERFLOW: Define to check suspicious overflow in the generic tests (tgeneric.c). For developers and testers. + MPFR_TESTS_MEMORY_LIMIT: The memory limit for the tests (default is 2^22 = 4 MB). Set to 0 for unlimited. + MPFR_TESTS_TIMEOUT: When timeout in the tests is enabled, this overrides the value of the macro. =========================================================================== Before testing any macro in a .c file, one needs: #ifdef HAVE_CONFIG_H # include "config.h" #endif except if mpfr-impl.h (for the library) or mpfr-test.h (for the tests) is included first, because these header files already have the above code. =========================================================================== The GNU Coding standards can be read at: https://www.gnu.org/prep/standards/ ISO C Names and corresponding headers: http://www.schweikhardt.net/identifiers.html The C language: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf (C99) http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf (C11 draft) http://home.datacomm.ch/t_wolf/tw/c/c9x_changes.html About undefined behavior: https://blog.regehr.org/archives/213 https://blog.regehr.org/archives/226 https://blog.regehr.org/archives/232 https://blog.regehr.org/archives/1520 http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html Type punning, strict aliasing, and optimization: https://blog.regehr.org/archives/959 To allow MPFR to be built on some buggy compiler, try to follow these rules: ===================================================================== Don't write: mp_limb_t l; [...] if (l) do_action (); But: mp_limb_t l; [...] if (l != 0) do_action (); since mp_limb_t may be "unsigned long long", and some buggy compiler produce illegal codes with the first form. ===================================================================== Try to avoid "LONG_MIN/1" since it produces a SIGNAL on (old) FreeBsd. Don't forget that LONG_MIN/-1 is not representable (specially with code like MPFR_EXP_MIN/n). ===================================================================== Don't use "near" and "far" as variable names since they are "Keywords" for some C compiler (Old DOS compiler). Also don't use "pm", which is used by the C compiler 'sharp' to design variables that should be stored in the flash memory. Don't use "new", which is reserved in C++. Check C++ reserved keywords, e.g. from https://en.cppreference.com/w/cpp/keyword or more generally: https://www.google.com/search?q=%22C%2B%2B%22+reserved+keywords Quoted from : Avoid the use of identifiers or idioms that would prevent code compiling with a C++ compiler. Identifiers such as new or class, that are reserved words in C++, should not be used as variables or field names. Explicit casts should be used to convert between void* and other pointer types. When a string literal ("...") is followed by a macro name, there must be white space between them, otherwise this is parsed as a user-defined string literal in C++11: https://en.cppreference.com/w/cpp/language/user_literal https://stackoverflow.com/a/6402166/3782797 In at least mpfr.h, use the underscore version of the attribute names (e.g. "__sentinel__" instead of "sentinel"), otherwise user code could fail to compile with GCC when it defines macros such as "sentinel" (before the #include's or via the -D command-line option). See https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html ===================================================================== Setting errno is safe to signal some error information (as in the formatted output functions), but errno must not be read (unless we have just modified it) as this may yield undefined behavior in some corner cases out of our control (ISO C99 / C11, 7.14.1.1p5, also mentioned in J.2). ===================================================================== C-Reduce may be useful to try to identify whether a bug comes from the compiler. ===================================================================== About type conversions: To do type punning (i.e. store a value of some type and reinterpret it as another type), use a union. This is valid in ISO C99 and above (in C99, see 6.5#7 and Note 82 of 6.5.2.3#3 for the clarification), but not in C++. So, users of a C++ compilers should make sure that their compiler supports type punning via a union. If some problem is reported, we should address it either by making the code compatible or by adding a configure test to reject the compiler. Some references: * https://en.wikipedia.org/wiki/Type_punning#Use_of_union * https://stackoverflow.com/questions/346622/opinions-on-type-punning-in-c "Opinions on type-punning in C++?" Do not do conversions between function pointers and other kinds of pointers (including to void *). This yields undefined behavior and may not work in practice. Example: https://stackoverflow.com/questions/5579835/c-function-pointer-casting-to-void-pointer Adding a level of indirection is OK, as suggested there, and on: https://stackoverflow.com/questions/36645660/why-cant-i-cast-a-function-pointer-to-void ===================================================================== For floating-point constants, do not use the non-standard and useless suffix "D". It seems to mean "double" for GCC[*], but for instance, ICC 15 regards 1.0D as 0 (though ICC claims compatibility with GCC) and for tcc 0.9.27, this is an error. The standard suffixes from TS 18661-2 are: f l F L df dd dl DF DD DL Moreover, avoid native floating-point if possible. Be careful that GCC does not conform to the C standard by default. References: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957 [*] https://stackoverflow.com/questions/4331200/what-do-f-and-d-mean-at-the-end-of-numeric-literals =========================================================================== Avoid variable names "l", "I" and "O", which look like "1" and "0" with some fonts. =========================================================================== For identifiers defined in MPFR, do not use the GMP namespaces (gmp_..., GMP_...). =========================================================================== You are allowed to use the mpn and mpz classes of GMP functions (types and functions starting with "mpn_" and "mpz_"). However, except for some conversion functions where they may be needed, * the mpq class and GMP's formatted output and input functions (i.e., printf and scanf style) can only be used in an alternative method by testing MPFR_USE_MINI_GMP (and only if there is a real benefit), since they are not available in mini-gmp; * the mpf class must not be used at all. =========================================================================== The headers , , and are always included in mpfr-impl.h; thus you need not (and should not) include them in usual source and test files. =========================================================================== For files that need intmax_t or similar, use: #if HAVE_INTTYPES_H # include #endif #if HAVE_STDINT_H # include #endif Note that even though the ISO C99 standard requires that include , in practice this is not true on all platforms, such as OSF/1 (Tru64) 5.1. This is consistent with autoconf, which has used this form since 2004-01-26 (in headers.m4). References: https://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=62ac9bbfebe879581dabeed78c6ac66b907dd51d https://sympa.inria.fr/sympa/arc/mpfr/2010-08/msg00015.html =========================================================================== Use locale-dependent functions when the result needs to depend on the locales, e.g. the decimal-point character in mpfr_out_str. Conversely, do not use locale-dependent functions when the result must not depend on the locales. In particular, the alphanumeric characters used in number strings (as created by mpfr_get_str) must be those of the required characters from the basic character set (see ISO C99 standard Section 5.2.1 "Character sets"). And tolower(letter) does not necessarily return the corresponding lowercase letter from these required characters. For instance, tolower('I') returns a dotless 'i' in Turkish tr_TR.iso88599 locales. =========================================================================== If you have to mix TMP_DECL and MPFR_SAVE_EXPO_DECL in the declaring section of your function, please declare MPFR_SAVE_EXPO_DECL before TMP_DECL, since TMP_DECL may be replace by nothing: Instead of: Usually preprocessed as: unsigned long t unsigned long t; TMP_DECL (marker); ; MPFR_SAVE_EXPO_DECL (expo); mpfr_save_expo_t expo; use: unsigned long t unsigned long t; MPFR_SAVE_EXPO_DECL (expo); mpfr_save_expo_t expo; TMP_DECL (marker); ; =========================================================================== Memory allocation ----------------- Do not use TMP_DECL / TMP_ALLOC, ... but MPFR_TMP_DECL, MPFR_TMP_ALLOC, ... In the tests, use only tests_allocate, tests_reallocate and tests_free (there may be some rare exceptions, such as in tabort_defalloc*.c). Avoid code that would yield unnecessary reallocations, which can be very expensive. In particular, for code that is based on the mpz layer of GMP, do not use mpz_init, but mpz_init2 with the estimated maximum size; it is better to overestimate this size a bit than underestimating it. =========================================================================== Do not use C99-only features, such as empty macro arguments or C++-style comments. =========================================================================== When testing a "boolean" macro M (i.e. which is normally either equal to 1 or undefined), do not use #if M, but #ifdef M or #if defined(M). With icc, the form #if M triggers a warning ("remark #193: zero used for undefined preprocessing identifier"). =========================================================================== If you want to use the logging of MPFR, you need to enable it: make distclean ./configure --enable-logging make Then link your program with this new build of MPFR. Warning! The logging code for functions sometimes output an "inexact" value, but in case of exception, this value may be meaningless. In fact, the output value is the value of some variable; please check the source code of the function to understand its real meaning. You can control what is logged using the environment variables: MPFR_LOG_FILE: Name of the LOG file (default: mpfr.log). MPFR_LOG_FLUSH: When this variable is set, flush the log stream after each log output (useful to get the latest logs in case of crash, but this makes logging slower). MPFR_LOG_PREC: Number of digits of the output (set the internal variable mpfr_log_prec, default: 6). MPFR_LOG_LEVEL: Max recursive level (default: 7). MPFR_LOG_INPUT: Log the input MPFR_LOG_OUTPUT: Log the output MPFR_LOG_TIME: Log the time spent inside the function. MPFR_LOG_INTERNAL: Log the intermediary variables if any. MPFR_LOG_MSG: Log the messages sent by MPFR if any. MPFR_LOG_ZIV: Log what the Ziv Loops do. MPFR_LOG_STAT: Log how many times Ziv failed. MPFR_LOG_ALL: Log everything Define them. Run your program, and view `mpfr.log`. For example, just define MPFR_LOG_ALL, run you program, and view `mpfr.log`. Note: The running time may be much longer. If logging is used on the test suite with a default timeout, it may be necessary to increase the timeout time by setting the environment variable MPFR_TESTS_TIMEOUT to the new timeout value in seconds (or 0 to disable the timeout). =========================================================================== This feature is available only for gcc >= 3.0 and glibc >= 2.0. To achieve this, these macros have been added: +++ MPFR_LOG_VAR(y) Log a MPFR variable if requested (INTERNAL). Example: mpfr_t y; MPFR_LOG_VAR (y); +++ MPFR_LOG_MSG(x) Log another message (a warning for example) Example: MPFR_LOG_MSG (("WARNING: Unchecked code\n", 0)); The 0 is here a dummy value, because there must be at least an argument after the format string. +++ MPFR_LOG_BEGIN(x) Add this macro at the beginning of a function. Example: int dodo (mpfr_t x, mpfr_t op, int cnt, mpfr_rnd_t rnd) { [decl] MPFR_LOG_BEGIN (("op[%Pu]=%.*Rg rnd=%s", mpfr_get_prec(op), mpfr_log_prec, op, RND2STR(rnd))); +++ MPFR_LOG_END(x) Add this macro at the end of a function. Example: MPFR_LOG_END (("x[%Pu]=%.*Rg i=%d", mpfr_get_prec (x), mpfr_log_prec, x, i)); return i; } +++ MPFR_LOG_FUNC (begin,end) Add this macro at the beginning of a function. It does the same job as MPFR_LOG_BEGIN and MPFR_LOG_END but it is smatter since it intercepts the return itself to put the end statement. Example MPFR_LOG_FUNC ( ("op[%Pu]=%.*Rg rnd=%d", op, mpfr_get_prec (op), mpfr_log_prec, op), ("x[%Pu]=%.*Rg inexact=%d", mpfr_get_prec (x), mpfr_log_prec, x, i)); The double brackets "((" and "))" are needed since MPFR must still compile with non GNU compiler, so Macros with variable # of args are not allowed. It uses the extension of the mpfr_printf function: %Rf to display a mpfr_t. %Ru is used to display the precision of a mpfr_t. It uses some extended attributes of GCC (constructor, etc.) to achieve its goals too. =========================================================================== ZivLoop Controller Ziv strategy is quite used in MPFR. In order to factorize the code, you could use these macros: +++ MPFR_ZIV_DECL(_x) Declare a ZivLoop controller +++ MPFR_ZIV_INIT(_x, _prec) Init a ZivLoop controller according to the initial value of _prec. +++ MPFR_ZIV_NEXT(_x, _prec) Increase the precision _prec according to the ZivLoop controller. +++ MPFR_ZIV_FREE(_x) Free the ZivLoop controller. =========================================================================== If you plan to add a new function, you could follow this schema: int mpfr_toto (mpfr_ptr rop, mpfr_srcptr op, mpfr_rnd_t rnd) { [Declare all used variables] int inexact; mpfr_prec_t prec; MPFR_ZIV_DECL (loop); MPFR_SAVE_EXPO_DECL (expo); /* Log it if requested */ MPFR_LOG_BEGIN (("op[%Pu]=%.*Rg rnd=%d", mpfr_get_prec (op), mpfr_log_prec, op, rnd), ("rop[%Pu]=%.*Rg inexact=%d", mpfr_get_prec (rop), mpfr_log_prec, rop, inexact)); /* First deal with particular cases */ if (MPFR_UNLIKELY (MPFR_IS_SINGULAR (op))) { if (MPFR_IS_NAN (op)) { MPFR_SET_NAN (rop); MPFR_RET_NAN; } else if (MPFR_IS_INF (op)) { [Code to deal with Infinity] } else { MPFR_ASSERTD (MPFR_IS_ZERO (op)); [Code to deal with Zero] } } [Other particular case: For example, op<0 or op == 1] [Compute the first estimation of the used precision `prec`] [Initialize the intermediate variables using mpfr_init2] MPFR_SAVE_EXPO_MARK (expo); /* Maximal range for exponent */ MPFR_ZIV_INIT (loop, prec); /* Initialize the ZivLoop controller */ for (;;) /* Infinite loop */ { [Compute an estimation of the function and] [an estimate of the error.] if (MPFR_CAN_ROUND (...)) /* If we can round, quit the loop */ break; MPFR_ZIV_NEXT (loop, prec); /* Increase used precision */ [Use `mpfr_set_prec` to resize all needed intermediate variables] } MPFR_ZIV_FREE (loop); /* Free the ZivLoop Controller */ inexact = mpfr_set (rop, temp, rnd); /* Set rop to the computed value */ [Clear all intermediate variables] MPFR_SAVE_EXPO_FREE (expo); /* Restore exponent range */ return mpfr_check_range (rop, inexact, rnd); /* Check range and quit */ } Make sure that Ziv loops cannot increase the precision forever because of internal exception. Otherwise one gets either a segmentation fault (with limited stack size) or an assertion failure (with unlimited stack size, e.g. with "make check"). Do not use code with side effects inside MPFR_ASSERTD or MPFR_ASSERTN, as assertion checking can be disabled. If a variable is set only to test it in an MPFR_ASSERTD expression, the MPFR_DBGRES macro should be used with the assignment as its argument, e.g. int inex; MPFR_DBGRES (inex = mpfr_set (y, x, rnd)); MPFR_ASSERTD (inex == 0); Exception handling (overflow/underflow in particular): * Warning: To detect exceptions and/or possible error loss due to internal exceptions, testing whether some variable is singular with MPFR_IS_SINGULAR is generally not sufficient! Indeed, in case of overflow (resp. underflow), the value may be rounded (in absolute value) to the largest finite number (resp. to the smallest non-zero number, possible even in round-to-nearest mode). * The MPFR_BLOCK* macros can be useful, e.g. { MPFR_BLOCK_DECL (flags); /* ... */ MPFR_BLOCK (flags, /* expression or statements */) /* ... */ if (MPFR_OVERFLOW (flags)) { /* case of overflow in expression or statements */ } /* ... */ } See mpfr-impl.h (search for MPFR_BLOCK) for more information. =========================================================================== If you plan to add a new threshold in MPFR which could be tuned, you should add its default value in the file `mparam_h.in'. When the script configure finishes, it creates the file `mparam.h' from `mparam_h.in'. Then you needs to modify the program `tuneup.c' to allow it to compute the new threshold. If it is a classical threshold (not complex), you could use this method (example of mpfr_exp): /* Define the threshold as a variable instead of a constant */ mpfr_prec_t mpfr_exp_threshold; #undef MPFR_EXP_THRESHOLD #define MPFR_EXP_THRESHOLD mpfr_exp_threshold /* Include the test function to threshold directly in the test program. It will override the mpfr_exp coming from libmpfr.a */ #include "exp.c" /* Define the speed function related to mpfr_exp */ static double speed_mpfr_exp (struct speed_params *s) { SPEED_MPFR_FUNC (mpfr_exp); } Then in the function `all', you will have to call the tune function, and write the new THRESHOLD in the file `mparam.h': /* Tune mpfr_exp */ if (verbose) printf ("Tuning mpfr_exp...\n"); tune_simple_func (&mpfr_exp_threshold, speed_mpfr_exp); fprintf (f, "#define MPFR_EXP_THRESHOLD %lu\n", (unsigned long) mpfr_exp_threshold); More complex tuning is possible but needs special attention. =========================================================================== MPFR uses many macros, thus finding where an error occurs exactly may be difficult when it is in some macro expansion. For GCC users, a new experimental -ftrack-macro-expansion option has been added in GCC 4.7. "It allows the compiler to emit diagnostic about the current macro expansion stack when a compilation error occurs in a macro expansion." =========================================================================== Bit Twiddling Hacks - Sean Eron Anderson maintain a list of tricks to get efficient code on . WARNING: some of those tricks may not take into account possible overflows, and may not be portable. =========================================================================== MPFR manual (mpfr.texi): * Use "significand", not "mantissa". * Use "decimal-point character" (as in ISO C) when the meaning is the corresponding character ("." or ",", depending on the locale), not "decimal point", "decimal separator", "fractional point", or "radix point" (the latter is fine in certain contexts). This is just the name of this character (as initially defined for base 10) and does not imply a number written in decimal. * Use "@minus{}" for the minus character, not "-". * Warning! Texinfo is not like TeX. Whitespace is preserved in the info file. So, do not use additional space for .texi indentation. This also means that you need to care about the typography. Please read Section "Inserting Space" in the Texinfo manual. * Follow the English typography (no space before punctuation marks, double space after a period, etc.), not the French one. The MPFR manual in DVI/PS/PDF formats should have an a4 papersize, as declared in mpfr.texi (@afourpaper command). The DVI file format (.dvi) traditionally does not contain papersize information, which has two consequences: * When viewing a .dvi file, one gets the papersize from global settings, which may differ from the papersize declared in the mpfr.texi file. In particular, a4 text on letter paper can be truncated, depending on the margins. * Since the .ps file is built from the .dvi file and makeinfo does not provide the papersize information to the dvips command, the .ps file can get a wrong papersize, depending on the settings on the machine where this file is generated. Papersize information should be checked before distributing the .ps file. Nowadays, .dvi files can contain papersize information via "specials", and texinfo.tex has been updated to include such information. However, the interpretation of such data is based on a common agreement between drivers rather on a standard. In short, the papersize issues should no longer appear, but this should be checked manually. The bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874632 =========================================================================== Running "make" outputs a lot of information, and warnings are not very visible. The following tool "eet" allows a copy of warning messages to be output to a different window (e.g. xterm or zenity): https://www.vinc17.net/unix/#eet Direct link to the tarball: https://www.vinc17.net/unix/eet.tar.xz =========================================================================== Be careful when avoiding "'var' may be used uninitialized in this function" warnings from gcc. Initializing such variables to a dummy value has several drawbacks: * this may prevent other tools (that do static or dynamic analysis) from detecting bugs; * this makes code maintenance more difficult (e.g. when modifying the code, one may more easily forget a real initialization); * this makes the compiler add useless code (though this should not be significant). The INITIALIZED macro can be used to avoid such warnings with gcc, e.g. int INITIALIZED(i); It uses the "int i = i;" pseudo-initialization trick, disabled with other compilers as this is undefined behavior. See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296 If a dummy initialization must be added, use preferably an "invalid" value (e.g. NULL for pointers, or a value that can be checked with MPFR_ASSERTN before using it) that could make the program abort instead of returning an incorrect value in case of a bug in MPFR. =========================================================================== Avoid mixing signed and unsigned integer types, as this can lead signed types to be automatically converted into unsigned types (usual arithmetic conversions). If such a signed type contains a negative value, the result may be incorrect on some platforms. With MPFR 2.x, this problem could arise with mpfr_exp_t, which is signed, and mpfr_prec_t (mp_prec_t), which was unsigned (it is now signed), meaning that in general, a cast of a mpfr_prec_t to a mpfr_exp_t was needed. Note that such bugs are difficult to detect because they may depend on the platform (e.g., on LP64, 32-bit unsigned int + 64-bit long will give a signed type, but on ILP32, 32-bit int + 32-bit unsigned long will give an unsigned type, which may not be what is expected), but also on the input values. So, do not rely on tests very much. However, if a test works on 32 bits but fails on 64 bits in the extended exponent range (or conversely), the cause may be related to the integer types (e.g. a signness problem or an integer overflow due to different type sizes). For instance, in MPFR, such issues were fixed in r1992 and r5588. An example that will fail with 32-bit int and long: long long umd(void) { long a = 1; unsigned int b = 2; return a - b; } When creating a new variable that will always contain nonnegative values, it is generally better to define it as a signed type if it may be used in an arithmetic expression. The exceptions are when the value is seen as an array of bits (e.g. for limbs) and to temporarily avoid integer overflow. =========================================================================== To use features related to types larger than type long, "mpfr-intmax.h" must be included before "mpfr-impl.h". The intmax_t and uintmax_t types can be used only if _MPFR_H_HAVE_INTMAX_T is defined. In this case, the printf / gmp_printf length specifier "j" can be used only when NPRINTF_J is not defined. For internal use, mpfr-intmax.h also unconditionally defines mpfr_intmax_t, mpfr_uintmax_t, MPFR_UINTMAX_MAX, MPFR_INTMAX_MAX, MPFR_INTMAX_MIN and the corresponding length specifier MPFR_INTMAX_FSPEC. Warning! mpfr_intmax_t may be smaller than intmax_t if NPRINTF_J is defined. =========================================================================== Use mpfr_prec_t and mpfr_rnd_t instead of the old types mp_prec_t and mp_rnd_t. Similarly, use mpfr_exp_t instead of GMP's mp_exp_t type (unless you really want mp_exp_t, e.g. for conversions with mpf; but you must not assume that mpfr_exp_t and mp_exp_t are identical). =========================================================================== How to specify (for reading) the minimum exponent or the maximum exponent in the MPFR source depends on the context. 1. The most portable form is mpfr_get_emin() and mpfr_get_emax(). In the MPFR source, this is equivalent to __gmpfr_emin and __gmpfr_emax respectively (macros are defined in mpfr-impl.h; the only difference is that the macros do not evaluate to a lvalue). 2. If the exponent range has been extended, you can use the constants MPFR_EMIN_MIN and MPFR_EMAX_MAX instead. This will be faster if TLS is enabled. It also avoids a bug on some Linux/Sparc machines with some GCC versions and TLS, but this shouldn't be the primary concern, as this might be the other way round on some other machines. This is the most common context. 3. If you want the minimum and maximum possible exponent values supported by MPFR, use MPFR_EMIN_MIN and MPFR_EMAX_MAX respectively. 4. If you want the minimum and maximum values supported by the mpfr_exp_t type (i.e. the limits of this type), use MPFR_EXP_MIN and MPFR_EXP_MAX respectively. This may be useful for intermediate computations on the exponents. More on exponent handling: * The mpfr_exp_t type has at least 32 bits since it must contain the default exponent range. * The range of valid exponents is defined so that if a and b are two valid exponents (i.e. between MPFR_EMIN_MIN and MPFR_EMAX_MAX), then ± a ± b ± 1 fits in a mpfr_exp_t. * The unsigned type corresponding to mpfr_exp_t is mpfr_uexp_t. It may be useful if the considered values are nonnegative and don't necessarily fit in mpfr_exp_t. To convert a nonnegative mpfr_exp_t to mpfr_uexp_t, you should use the MPFR_UEXP macro, which is defined as: #define MPFR_UEXP(X) (MPFR_ASSERTD ((X) >= 0), (mpfr_uexp_t) (X)) * If a mpfr_exp_t appears in arithmetic expressions together with ISO C90 types int and/or long, computations must be done with the largest type, which is provided by mpfr_eexp_t. * If a mpfr_exp_t needs to be converted from or to a MPFR number, the mpfr_set_exp_t or mpfr_get_exp_t macro should be used. * If a mpfr_exp_t needs to be converted into a character string with a formatted output function (fprintf, printf, sprintf), the mpfr_eexp_t type should be used, together with the MPFR_EXP_FSPEC specifier, e.g. printf ("%" MPFR_EXP_FSPEC "d", (mpfr_eexp_t) exponent); For implementation details, see the mpfr.h and mpfr-impl.h files. =========================================================================== Be careful that the ternary value (a.k.a. "inexact") is not guaranteed to be -1, 0, or 1, in general (for some functions, the exact value may contain other information, such as midpoint cases with MPFR_EVEN_INEX), and the exact behavior may change in the future. So, it is not correct to multiply ternary values returned by arbitrary functions as this may overflow. To work with ternary values, mpfr-impl.h provides the following macros: #define SIGN(I) ((I) < 0 ? -1 : (I) > 0) #define SAME_SIGN(I1,I2) (SIGN (I1) == SIGN (I2)) =========================================================================== Because of a bug in the Mac OS X 10.5 linker, avoid tentative definitions (C99, 6.9.2). Depending on the context, use either a simple declaration (with the "extern" storage-class specifier) or an external definition. This is also cleaner. =========================================================================== In case of detected internal error, do not use printf() and exit(). Use assertions (MPFR_ASSERTN) instead. =========================================================================== When using GNU extensions (based on the value of the __GNUC_* macros), check whether they work with ICC. The following paper can give useful information: "Intel® Compilers for Linux*: Compatibility with GNU Compilers" at . To detect compilers, see https://sourceforge.net/p/predef/wiki/Compilers/ =========================================================================== For configure tests, use AC_LINK_IFELSE rather than AC_COMPILE_IFELSE, which is broken by design. The reason is that some errors just produce a warning (which is not a bug from the compiler: in ISO C terminology, this corresponds to a diagnostic, and the compilation is allowed to succeed), and this is unfixable in a portable way. =========================================================================== Shell portability ----------------- Shell commands (in /bin/sh scripts, in Makefile and autotools related files...) need to be valid in POSIX shells, but also in Bourne shells (for instance, /bin/sh under Solaris is a Bourne shell). In particular: * Do not use $(...) but `...` (backticks). * Be careful that quote nesting with backticks such as "`cmd "$foo"`" is not portable: https://unix.stackexchange.com/q/387246/74516 ("quotes inside backticks inside quotes in ksh") But the external quotes are not needed when assigning to a variable: out=`cmd "$foo"` Otherwise one can write "`cmd \"$foo\"`". =========================================================================== For developers - Use of the svn:eol-style Subversion property The svn:eol-style Subversion property is traditionally set to "native" on text files, but this has drawbacks: * On systems where the end-of-line (EOL) sequence is not LF, the obtained files are different from those from the tarballs. This makes maintenance harder. * Some tools under Windows (such as makeinfo of MinGW/MSYS) don't support the MS-Windows EOL sequence CRLF, and the MPFR build fails. For these reasons, the svn:eol-style Subversion property should never be set to "native". =========================================================================== About the test suite -------------------- When adding a test file for a new function (say mpfr_func), you can use the following prototype tfunc.c (to put in the directory 'tests'). This file performs random tests for values of x between -5 and 5, with a precision varying from 2 to 100. You can add your own tests to this basic file. When adding the expected result, do NOT use the one obtained from the MPFR function! Otherwise, if this function is buggy, the test will be wrong and the function will remain buggy. For random tests, avoid mpfr_urandomb as its values are not truly random due to how it is specified (if the exponent is less than 0, some of the trailing bits will necessarily be 0). Do not forget to add 'tfunc' in the variable check_PROGRAMS of the tests/Makefile.am file. /* Test file for mpfr_func. Copyright 2020 Free Software Foundation, Inc. Contributed by the AriC and Caramba projects, INRIA. This file is part of the GNU MPFR Library. The GNU MPFR Library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version. The GNU MPFR Library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with the GNU MPFR Library; see the file COPYING.LESSER. If not, see https://www.gnu.org/licenses/ or write to the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA. */ #include "mpfr-test.h" #define TEST_FUNCTION mpfr_func #define TEST_RANDOM_EMIN -5 #define TEST_RANDOM_EMAX 5 #include "tgeneric.c" int main (int argc, char *argv[]) { tests_start_mpfr (); test_generic (2, 100, 100); tests_end_mpfr (); return 0; } --------------------------------------------------------------------- Here is how the test suite works since the full Automake 1.13 support (merge of the vl-am113 branch in r8821). The tests_start_mpfr function, which should be called at the beginning of each test program (unless nothing is tested and main() just contains "return 77;"), starts by calling the test_version function, whose goal is to do various header/library version checks of GMP and MPFR. In case of mismatch between a header and a library, an error message is output ("make check" will redirect it to a log file). Then there are 3 cases: 1. An error in the MPFR version check is a fatal error: test_version() exits with an error (exit status = 1). The reason is that a different MPFR library (somewhere in some library search path) would probably be tested, so that the results of the test would be meaningless. 2. An error in the GMP version check is a non-fatal error: if there are no errors in MPFR version check, test_version() returns with value 1. However the tversion test program will regard this as a fatal error (thus "make check" will fail). The probable reason of the mismatch is that the GMP library has been upgraded while the MPFR test suite has not been rebuilt; otherwise there is probably something wrong in the GMP installation. 3. Otherwise test_version() returns with value 0 (everything is fine). Note: The tests_start_mpfr function does a setbuf on stdout to disable buffering. As a consequence, no operations on stdout (such as printf) must be done before this function is called. With Automake 1.13+, the tests are run in parallel if a -j make option is used. In case of failure, information can be found in the log file of each failed test program and in the global tests/test-suite.log file (which is output automatically if the VERBOSE environment variable is set to 1). If no tests fail, then the tests/tversion.log file is output after the "testsuite summary"; it contains various useful information about the MPFR build. To use a wrapper to run the tests, such as valgrind or wine, define LOG_COMPILER, e.g.: LOG_COMPILER="valgrind -q --error-exitcode=1 --leak-check=full" make check LOG_COMPILER=wine make check More information about the parallel test harness: https://www.gnu.org/software/automake/manual/automake.html#Parallel-Test-Harness --------------------------------------------------------------------- In the tests, do not use `mpfr_set_d` (except when testing it), as the result will depend on the floating-point arithmetic of the system; this has shown many problems in the past and problems may still occur with new systems. Use `mpfr_set_si` or `mpfr_set_str` instead. To check the result of some function, use mpfr_equal_p rather than mpfr_cmp, as mpfr_cmp will return 0 (equality) if the result is NaN. Do not use functions that need optional features (except in a context where such features are required). For instance, the mpfr_printf-like functions need (HAVE_STDARG defined), thus should not be used, except for testing them. For temporary result files created by test programs, choose a unique filename to avoid conflicts in parallel tests. To ensure that, the filename should start with the name of the test program (for instance, "tfprintf_out.txt" for tfprintf.c). Add the filename to CLEANFILES in the tests/Makefile.am file. Also, make sure that the tests run against previous MPFR versions, possibly by disabling some tests with code like #if MPFR_VERSION >= MPFR_VERSION_NUM(2,3,0) Indeed one can now easily run the trunk tests in a branch by executing svn switch .../svn/mpfr/trunk/tests tests from the working copy. One can know when the tests directory has been switched, thanks to $ svn status S tests In case of failure, freeing the memory explicitly is not necessary. We do this in case of success just to be able to detect memory leaks in MPFR. --------------------------------------------------------------------- To check the coverage of the test suite, you can use gcov. To get accurate information, do not enable optimizations. ./configure CFLAGS="--coverage" make clean make check find . -name '*.c' -exec gcov '{}' ';' | grep "lines executed" | sort For each source file, there is a .c.gcov file which contains much more information. Another solution is to run the script 'coverage' within the 'tools' directory. --------------------------------------------------------------------- To run the MPFR test suite under valgrind, you may need to do several things. First, as the running time is much longer than usual, you should not use the --enable-tests-timeout configure option, or set the timeout value to a large value; this can be done at run time, e.g. with export MPFR_TESTS_TIMEOUT=0 to disable the timeout, so that you do not need to rebuild MPFR for this purpose. Then just set the LOG_COMPILER environment variable to something like valgrind -q --error-exitcode=1 --leak-check=full before running "make check", or type directly: LOG_COMPILER="valgrind -q --error-exitcode=1 --leak-check=full" make check NOTE: with the new tests/Makefile.am file, the following is obsolete; but it might still be useful under some occasions, e.g. if all the valgrind output needs to be sent to a single file. Before running valgrind, you should run "make check" a first time so that everything is compiled out of valgrind. Then you need the --trace-children=yes valgrind option (a possible exception is when you run an individual test that has been built statically). The reason is that libtool generates wrapper scripts to link the tests against the right libraries. The drawback is that you will get valgrind output for all the processes, including the shell commands from the wrapper scripts (the --trace-children-skip valgrind option will not allow you to filter every unwanted process). But you can filter the output with: sed -n '/= Command: [^ ]*\/\.libs\/lt-/,/= ERROR SUMMARY:/p' For readability, you should redirect the valgrind output to a file. You can use --log-file, but due to --trace-children=yes, you need the %p format specifier in the filename argument to generate a file for each child; however many files will be generated, and it may be better to use the following method to get a single file: valgrind --trace-children=yes --log-fd=3 make check 3> vg.out then sed -n '/= Command: [^ ]*\/\.libs\/lt-/,/= ERROR SUMMARY:/p' vg.out to get only the valgrind output corresponding to the MPFR tests. Or if your shell supports it, you can use a process substitution to filter the valgrind output directly to a file, e.g. with bash or zsh: valgrind --trace-children=yes --log-fd=3 make check 3> >(sed -n \ '/= Command: [^ ]*\/\.libs\/lt-/,/= ERROR SUMMARY:/p' > vg.out) if you do not mind about the buffering delays. --------------------------------------------------------------------- NOTE: with "AM_LDFLAGS = -no-install" in tests/Makefile.am, the following is obsolete, as libtool no longer generates wrapper scripts; but it is left here in case negative effects of "AM_LDFLAGS = -no-install" are seen or for users with a special setup. To debug some test program, e.g. tadd, with gdb, you cannot run "gdb tadd" since libtool has generated a wrapper script to link the program against the correct MPFR library. Instead, run: libtool --mode=execute gdb tadd Alternatively, something like LD_PRELOAD=../src/.libs/libmpfr.so gdb .libs/tadd may also work (example for GNU/Linux). Note: for test programs not listed in Makefile.am (check_PROGRAMS), libtool is not used (a static link against MPFR is done via LOADLIBES in Makefile.am), so that gdb should be used in the conventional way. You can use the following wrapper script to have a command that works with both: ------------------------------------------------------------ #!/bin/sh unset cmd case $1 in -*) ;; ?*) test "x$(head -c 2 "$1")" = 'x#!' && \ grep -q "^# Generated by libtool" "$1" && \ cmd="libtool --mode=execute" ;; esac exec $cmd gdb "$@" ------------------------------------------------------------ and alias gdb='/path/to/the/wrapper/script' =========================================================================== To cross-compile MPFR for i686-w64-mingw32 and test it under Wine: 0. Install wine (at least the 32-bit version). 1. Build and install GMP. In the GMP source directory: $ ./configure --host=i686-w64-mingw32 --disable-shared --prefix=... $ make $ make check LOG_COMPILER=wine $ make install Note: The -D__USE_MINGW_ANSI_STDIO option may be necessary in order to get an ISO-compliant printf as mentioned in MPFR's INSTALL file. In this case, add CC="i686-w64-mingw32-gcc -D__USE_MINGW_ANSI_STDIO" at the end of the configure line. Otherwise MPFR needs to be configured with "CPPFLAGS=-DNPRINTF_J -DNPRINTF_L -DNPRINTF_T" But with recent versions of the tools, printf now seems to be ISO-compliant by default. The __USE_MINGW_ANSI_STDIO macro is now internal to MinGW and should no longer be used. 2. Build and check MPFR. In the MPFR source directory: $ ./configure --host=i686-w64-mingw32 --disable-shared --with-gmp=... $ make $ make check LOG_COMPILER=wine Note: Due to bugs in autoconf[1] and dash[2], the configure script may create files with a binary filename or have any other arbitrary behavior if /bin/sh is dash. The cause is that it tries to execute a MS Windows executable, which is interpreted as a shell script by dash (thus with random, meaningless commands). This will confuse Subversion, and these files need to be removed manually. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850329 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816313 =========================================================================== After a MPFR build, the list of GMP symbols used by this particular MPFR build can be obtained as follows: nm -u src/.libs/libmpfr.so | sed -n 's/^ *U \(__gmp.*\)/\1/p' at least under Linux, the library name and the "nm" behavior being non-portable (adding the POSIX "-P" option may help, but there are still differences between platforms). Note that this list may depend on various parameters, such as the architecture and the compilation options. GMP internal symbols used by MPFR can be detected with the following shell command (just replace /path/to/gmp.h by the actual pathname): nm -u src/.libs/libmpfr.so | sed -n 's/^ *U \(__gmp.*\)/\1/p' | \ while read s do case $s in __gmpn_*) regex="__MPN(${s#__gmpn_})" ;; *) regex="$s" ;; esac grep -q "^#define .* ${regex}$" /path/to/gmp.h || echo "Internal: $s" done A similar check can be done with "make check-gmp-symbols". One can also check that MPFR does not define exported symbols with a prefix outside "mpfr_" and "__gmpfr_" by using "nm -g" and filtering at least the "U" lines. But this can only be a manual check to avoid false positives. Checking that a GMP reserved prefix is not used can be done automatically, as with "make check-exported-symbols". =========================================================================== To update the FAQ, checkout the misc directory of the repository root. Modify the faq.xhtml file and run xsltproc --nodtdattr faq-web.xsl faq.xhtml > www/faq.html Check with "svn diff" that this change has been done correctly (in case of incorrect installation of XML tools), validate the files with xmllint --noout --loaddtd --valid faq.xhtml www/faq.html and if everything is OK (no error messages), commit both files. Update the FAQ.html file with update-faq in the doc directory of the MPFR trunk and supported branches. =========================================================================== Spelling: * Some suggestions: https://gcc.gnu.org/codingconventions.html#Spelling * Check with "codespell" (done by mpfrlint). ======================================================================== * COPYING ======================================================================== GNU GENERAL PUBLIC LICENSE Version 3, 29 June 2007 Copyright (C) 2007 Free Software Foundation, Inc. Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Preamble The GNU General Public License is a free, copyleft license for software and other kinds of works. The licenses for most software and other practical works are designed to take away your freedom to share and change the works. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change all versions of a program--to make sure it remains free software for all its users. We, the Free Software Foundation, use the GNU General Public License for most of our software; it applies also to any other work released this way by its authors. You can apply it to your programs, too. When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for them if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs, and that you know you can do these things. To protect your rights, we need to prevent others from denying you these rights or asking you to surrender the rights. Therefore, you have certain responsibilities if you distribute copies of the software, or if you modify it: responsibilities to respect the freedom of others. For example, if you distribute copies of such a program, whether gratis or for a fee, you must pass on to the recipients the same freedoms that you received. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights. Developers that use the GNU GPL protect your rights with two steps: (1) assert copyright on the software, and (2) offer you this License giving you legal permission to copy, distribute and/or modify it. For the developers' and authors' protection, the GPL clearly explains that there is no warranty for this free software. For both users' and authors' sake, the GPL requires that modified versions be marked as changed, so that their problems will not be attributed erroneously to authors of previous versions. Some devices are designed to deny users access to install or run modified versions of the software inside them, although the manufacturer can do so. This is fundamentally incompatible with the aim of protecting users' freedom to change the software. The systematic pattern of such abuse occurs in the area of products for individuals to use, which is precisely where it is most unacceptable. Therefore, we have designed this version of the GPL to prohibit the practice for those products. If such problems arise substantially in other domains, we stand ready to extend this provision to those domains in future versions of the GPL, as needed to protect the freedom of users. Finally, every program is threatened constantly by software patents. States should not allow patents to restrict development and use of software on general-purpose computers, but in those that do, we wish to avoid the special danger that patents applied to a free program could make it effectively proprietary. To prevent this, the GPL assures that patents cannot be used to render the program non-free. The precise terms and conditions for copying, distribution and modification follow. TERMS AND CONDITIONS 0. Definitions. "This License" refers to version 3 of the GNU General Public License. "Copyright" also means copyright-like laws that apply to other kinds of works, such as semiconductor masks. "The Program" refers to any copyrightable work licensed under this License. Each licensee is addressed as "you". "Licensees" and "recipients" may be individuals or organizations. To "modify" a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a "modified version" of the earlier work or a work "based on" the earlier work. A "covered work" means either the unmodified Program or a work based on the Program. To "propagate" a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well. To "convey" a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying. An interactive user interface displays "Appropriate Legal Notices" to the extent that it includes a convenient and prominently visible feature that (1) displays an appropriate copyright notice, and (2) tells the user that there is no warranty for the work (except to the extent that warranties are provided), that licensees may convey the work under this License, and how to view a copy of this License. If the interface presents a list of user commands or options, such as a menu, a prominent item in the list meets this criterion. 1. Source Code. The "source code" for a work means the preferred form of the work for making modifications to it. "Object code" means any non-source form of a work. A "Standard Interface" means an interface that either is an official standard defined by a recognized standards body, or, in the case of interfaces specified for a particular programming language, one that is widely used among developers working in that language. The "System Libraries" of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A "Major Component", in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it. The "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work. The Corresponding Source need not include anything that users can regenerate automatically from other parts of the Corresponding Source. The Corresponding Source for a work in source code form is that same work. 2. Basic Permissions. All rights granted under this License are granted for the term of copyright on the Program, and are irrevocable provided the stated conditions are met. This License explicitly affirms your unlimited permission to run the unmodified Program. The output from running a covered work is covered by this License only if the output, given its content, constitutes a covered work. This License acknowledges your rights of fair use or other equivalent, as provided by copyright law. You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force. You may convey covered works to others for the sole purpose of having them make modifications exclusively for you, or provide you with facilities for running those works, provided that you comply with the terms of this License in conveying all material for which you do not control copyright. Those thus making or running the covered works for you must do so exclusively on your behalf, under your direction and control, on terms that prohibit them from making any copies of your copyrighted material outside their relationship with you. Conveying under any other circumstances is permitted solely under the conditions stated below. Sublicensing is not allowed; section 10 makes it unnecessary. 3. Protecting Users' Legal Rights From Anti-Circumvention Law. No covered work shall be deemed part of an effective technological measure under any applicable law fulfilling obligations under article 11 of the WIPO copyright treaty adopted on 20 December 1996, or similar laws prohibiting or restricting circumvention of such measures. When you convey a covered work, you waive any legal power to forbid circumvention of technological measures to the extent such circumvention is effected by exercising rights under this License with respect to the covered work, and you disclaim any intention to limit operation or modification of the work as a means of enforcing, against the work's users, your or third parties' legal rights to forbid circumvention of technological measures. 4. Conveying Verbatim Copies. You may convey verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice; keep intact all notices stating that this License and any non-permissive terms added in accord with section 7 apply to the code; keep intact all notices of the absence of any warranty; and give all recipients a copy of this License along with the Program. You may charge any price or no price for each copy that you convey, and you may offer support or warranty protection for a fee. 5. Conveying Modified Source Versions. You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions: a) The work must carry prominent notices stating that you modified it, and giving a relevant date. b) The work must carry prominent notices stating that it is released under this License and any conditions added under section 7. This requirement modifies the requirement in section 4 to "keep intact all notices". c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it. d) If the work has interactive user interfaces, each must display Appropriate Legal Notices; however, if the Program has interactive interfaces that do not display Appropriate Legal Notices, your work need not make them do so. A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an "aggregate" if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate. 6. Conveying Non-Source Forms. You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways: a) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by the Corresponding Source fixed on a durable physical medium customarily used for software interchange. b) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge. c) Convey individual copies of the object code with a copy of the written offer to provide the Corresponding Source. This alternative is allowed only occasionally and noncommercially, and only if you received the object code with such an offer, in accord with subsection 6b. d) Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge. You need not require recipients to copy the Corresponding Source along with the object code. If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements. e) Convey the object code using peer-to-peer transmission, provided you inform other peers where the object code and Corresponding Source of the work are being offered to the general public at no charge under subsection 6d. A separable portion of the object code, whose source code is excluded from the Corresponding Source as a System Library, need not be included in conveying the object code work. A "User Product" is either (1) a "consumer product", which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling. In determining whether a product is a consumer product, doubtful cases shall be resolved in favor of coverage. For a particular product received by a particular user, "normally used" refers to a typical or common use of that class of product, regardless of the status of the particular user or of the way in which the particular user actually uses, or expects or is expected to use, the product. A product is a consumer product regardless of whether the product has substantial commercial, industrial or non-consumer uses, unless such uses represent the only significant mode of use of the product. "Installation Information" for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made. If you convey an object code work under this section in, or with, or specifically for use in, a User Product, and the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized), the Corresponding Source conveyed under this section must be accompanied by the Installation Information. But this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM). The requirement to provide Installation Information does not include a requirement to continue to provide support service, warranty, or updates for a work that has been modified or installed by the recipient, or for the User Product in which it has been modified or installed. Access to a network may be denied when the modification itself materially and adversely affects the operation of the network or violates the rules and protocols for communication across the network. Corresponding Source conveyed, and Installation Information provided, in accord with this section must be in a format that is publicly documented (and with an implementation available to the public in source code form), and must require no special password or key for unpacking, reading or copying. 7. Additional Terms. "Additional permissions" are terms that supplement the terms of this License by making exceptions from one or more of its conditions. Additional permissions that are applicable to the entire Program shall be treated as though they were included in this License, to the extent that they are valid under applicable law. If additional permissions apply only to part of the Program, that part may be used separately under those permissions, but the entire Program remains governed by this License without regard to the additional permissions. When you convey a copy of a covered work, you may at your option remove any additional permissions from that copy, or from any part of it. (Additional permissions may be written to require their own removal in certain cases when you modify the work.) You may place additional permissions on material, added by you to a covered work, for which you have or can give appropriate copyright permission. Notwithstanding any other provision of this License, for material you add to a covered work, you may (if authorized by the copyright holders of that material) supplement the terms of this License with terms: a) Disclaiming warranty or limiting liability differently from the terms of sections 15 and 16 of this License; or b) Requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it; or c) Prohibiting misrepresentation of the origin of that material, or requiring that modified versions of such material be marked in reasonable ways as different from the original version; or d) Limiting the use for publicity purposes of names of licensors or authors of the material; or e) Declining to grant rights under trademark law for use of some trade names, trademarks, or service marks; or f) Requiring indemnification of licensors and authors of that material by anyone who conveys the material (or modified versions of it) with contractual assumptions of liability to the recipient, for any liability that these contractual assumptions directly impose on those licensors and authors. All other non-permissive additional terms are considered "further restrictions" within the meaning of section 10. If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term. If a license document contains a further restriction but permits relicensing or conveying under this License, you may add to a covered work material governed by the terms of that license document, provided that the further restriction does not survive such relicensing or conveying. If you add terms to a covered work in accord with this section, you must place, in the relevant source files, a statement of the additional terms that apply to those files, or a notice indicating where to find the applicable terms. Additional terms, permissive or non-permissive, may be stated in the form of a separately written license, or stated as exceptions; the above requirements apply either way. 8. Termination. You may not propagate or modify a covered work except as expressly provided under this License. Any attempt otherwise to propagate or modify it is void, and will automatically terminate your rights under this License (including any patent licenses granted under the third paragraph of section 11). However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation. Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice. Termination of your rights under this section does not terminate the licenses of parties who have received copies or rights from you under this License. If your rights have been terminated and not permanently reinstated, you do not qualify to receive new licenses for the same material under section 10. 9. Acceptance Not Required for Having Copies. You are not required to accept this License in order to receive or run a copy of the Program. Ancillary propagation of a covered work occurring solely as a consequence of using peer-to-peer transmission to receive a copy likewise does not require acceptance. However, nothing other than this License grants you permission to propagate or modify any covered work. These actions infringe copyright if you do not accept this License. Therefore, by modifying or propagating a covered work, you indicate your acceptance of this License to do so. 10. Automatic Licensing of Downstream Recipients. Each time you convey a covered work, the recipient automatically receives a license from the original licensors, to run, modify and propagate that work, subject to this License. You are not responsible for enforcing compliance by third parties with this License. An "entity transaction" is a transaction transferring control of an organization, or substantially all assets of one, or subdividing an organization, or merging organizations. If propagation of a covered work results from an entity transaction, each party to that transaction who receives a copy of the work also receives whatever licenses to the work the party's predecessor in interest had or could give under the previous paragraph, plus a right to possession of the Corresponding Source of the work from the predecessor in interest, if the predecessor has it or can get it with reasonable efforts. You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example, you may not impose a license fee, royalty, or other charge for exercise of rights granted under this License, and you may not initiate litigation (including a cross-claim or counterclaim in a lawsuit) alleging that any patent claim is infringed by making, using, selling, offering for sale, or importing the Program or any portion of it. 11. Patents. A "contributor" is a copyright holder who authorizes use under this License of the Program or a work on which the Program is based. The work thus licensed is called the contributor's "contributor version". A contributor's "essential patent claims" are all patent claims owned or controlled by the contributor, whether already acquired or hereafter acquired, that would be infringed by some manner, permitted by this License, of making, using, or selling its contributor version, but do not include claims that would be infringed only as a consequence of further modification of the contributor version. For purposes of this definition, "control" includes the right to grant patent sublicenses in a manner consistent with the requirements of this License. Each contributor grants you a non-exclusive, worldwide, royalty-free patent license under the contributor's essential patent claims, to make, use, sell, offer for sale, import and otherwise run, modify and propagate the contents of its contributor version. In the following three paragraphs, a "patent license" is any express agreement or commitment, however denominated, not to enforce a patent (such as an express permission to practice a patent or covenant not to sue for patent infringement). To "grant" such a patent license to a party means to make such an agreement or commitment not to enforce a patent against the party. If you convey a covered work, knowingly relying on a patent license, and the Corresponding Source of the work is not available for anyone to copy, free of charge and under the terms of this License, through a publicly available network server or other readily accessible means, then you must either (1) cause the Corresponding Source to be so available, or (2) arrange to deprive yourself of the benefit of the patent license for this particular work, or (3) arrange, in a manner consistent with the requirements of this License, to extend the patent license to downstream recipients. "Knowingly relying" means you have actual knowledge that, but for the patent license, your conveying the covered work in a country, or your recipient's use of the covered work in a country, would infringe one or more identifiable patents in that country that you have reason to believe are valid. If, pursuant to or in connection with a single transaction or arrangement, you convey, or propagate by procuring conveyance of, a covered work, and grant a patent license to some of the parties receiving the covered work authorizing them to use, propagate, modify or convey a specific copy of the covered work, then the patent license you grant is automatically extended to all recipients of the covered work and works based on it. A patent license is "discriminatory" if it does not include within the scope of its coverage, prohibits the exercise of, or is conditioned on the non-exercise of one or more of the rights that are specifically granted under this License. You may not convey a covered work if you are a party to an arrangement with a third party that is in the business of distributing software, under which you make payment to the third party based on the extent of your activity of conveying the work, and under which the third party grants, to any of the parties who would receive the covered work from you, a discriminatory patent license (a) in connection with copies of the covered work conveyed by you (or copies made from those copies), or (b) primarily for and in connection with specific products or compilations that contain the covered work, unless you entered into that arrangement, or that patent license was granted, prior to 28 March 2007. Nothing in this License shall be construed as excluding or limiting any implied license or other defenses to infringement that may otherwise be available to you under applicable patent law. 12. No Surrender of Others' Freedom. If conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot convey a covered work so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not convey it at all. For example, if you agree to terms that obligate you to collect a royalty for further conveying from those to whom you convey the Program, the only way you could satisfy both those terms and this License would be to refrain entirely from conveying the Program. 13. Use with the GNU Affero General Public License. Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU Affero General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the special requirements of the GNU Affero General Public License, section 13, concerning interaction through a network will apply to the combination as such. 14. Revised Versions of this License. The Free Software Foundation may publish revised and/or new versions of the GNU General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Program specifies that a certain numbered version of the GNU General Public License "or any later version" applies to it, you have the option of following the terms and conditions either of that numbered version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of the GNU General Public License, you may choose any version ever published by the Free Software Foundation. If the Program specifies that a proxy can decide which future versions of the GNU General Public License can be used, that proxy's public statement of acceptance of a version permanently authorizes you to choose that version for the Program. Later license versions may give you additional or different permissions. However, no additional obligations are imposed on any author or copyright holder as a result of your choosing to follow a later version. 15. Disclaimer of Warranty. THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 16. Limitation of Liability. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. 17. Interpretation of Sections 15 and 16. If the disclaimer of warranty and limitation of liability provided above cannot be given local legal effect according to their terms, reviewing courts shall apply local law that most closely approximates an absolute waiver of all civil liability in connection with the Program, unless a warranty or assumption of liability accompanies a copy of the Program in return for a fee. END OF TERMS AND CONDITIONS How to Apply These Terms to Your New Programs If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms. To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively state the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. Copyright (C) This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program. If not, see . Also add information on how to contact you by electronic and paper mail. If the program does terminal interaction, make it output a short notice like this when it starts in an interactive mode: Copyright (C) This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'. This is free software, and you are welcome to redistribute it under certain conditions; type `show c' for details. The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, your program's commands might be different; for a GUI interface, you would use an "about box". You should also get your employer (if you work as a programmer) or school, if any, to sign a "copyright disclaimer" for the program, if necessary. For more information on this, and how to apply and follow the GNU GPL, see . The GNU General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Lesser General Public License instead of this License. But first, please read . ======================================================================== * COPYING.LESSER ======================================================================== GNU LESSER GENERAL PUBLIC LICENSE Version 3, 29 June 2007 Copyright (C) 2007 Free Software Foundation, Inc. Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. This version of the GNU Lesser General Public License incorporates the terms and conditions of version 3 of the GNU General Public License, supplemented by the additional permissions listed below. 0. Additional Definitions. As used herein, "this License" refers to version 3 of the GNU Lesser General Public License, and the "GNU GPL" refers to version 3 of the GNU General Public License. "The Library" refers to a covered work governed by this License, other than an Application or a Combined Work as defined below. An "Application" is any work that makes use of an interface provided by the Library, but which is not otherwise based on the Library. Defining a subclass of a class defined by the Library is deemed a mode of using an interface provided by the Library. A "Combined Work" is a work produced by combining or linking an Application with the Library. The particular version of the Library with which the Combined Work was made is also called the "Linked Version". The "Minimal Corresponding Source" for a Combined Work means the Corresponding Source for the Combined Work, excluding any source code for portions of the Combined Work that, considered in isolation, are based on the Application, and not on the Linked Version. The "Corresponding Application Code" for a Combined Work means the object code and/or source code for the Application, including any data and utility programs needed for reproducing the Combined Work from the Application, but excluding the System Libraries of the Combined Work. 1. Exception to Section 3 of the GNU GPL. You may convey a covered work under sections 3 and 4 of this License without being bound by section 3 of the GNU GPL. 2. Conveying Modified Versions. If you modify a copy of the Library, and, in your modifications, a facility refers to a function or data to be supplied by an Application that uses the facility (other than as an argument passed when the facility is invoked), then you may convey a copy of the modified version: a) under this License, provided that you make a good faith effort to ensure that, in the event an Application does not supply the function or data, the facility still operates, and performs whatever part of its purpose remains meaningful, or b) under the GNU GPL, with none of the additional permissions of this License applicable to that copy. 3. Object Code Incorporating Material from Library Header Files. The object code form of an Application may incorporate material from a header file that is part of the Library. You may convey such object code under terms of your choice, provided that, if the incorporated material is not limited to numerical parameters, data structure layouts and accessors, or small macros, inline functions and templates (ten or fewer lines in length), you do both of the following: a) Give prominent notice with each copy of the object code that the Library is used in it and that the Library and its use are covered by this License. b) Accompany the object code with a copy of the GNU GPL and this license document. 4. Combined Works. You may convey a Combined Work under terms of your choice that, taken together, effectively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications, if you also do each of the following: a) Give prominent notice with each copy of the Combined Work that the Library is used in it and that the Library and its use are covered by this License. b) Accompany the Combined Work with a copy of the GNU GPL and this license document. c) For a Combined Work that displays copyright notices during execution, include the copyright notice for the Library among these notices, as well as a reference directing the user to the copies of the GNU GPL and this license document. d) Do one of the following: 0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source. 1) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user's computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version. e) Provide Installation Information, but only if you would otherwise be required to provide such information under section 6 of the GNU GPL, and only to the extent that such information is necessary to install and execute a modified version of the Combined Work produced by recombining or relinking the Application with a modified version of the Linked Version. (If you use option 4d0, the Installation Information must accompany the Minimal Corresponding Source and Corresponding Application Code. If you use option 4d1, you must provide the Installation Information in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.) 5. Combined Libraries. You may place library facilities that are a work based on the Library side by side in a single library together with other library facilities that are not Applications and are not covered by this License, and convey such a combined library under terms of your choice, if you do both of the following: a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities, conveyed under the terms of this License. b) Give prominent notice with the combined library that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work. 6. Revised Versions of the GNU Lesser General Public License. The Free Software Foundation may publish revised and/or new versions of the GNU Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Library as you received it specifies that a certain numbered version of the GNU Lesser General Public License "or any later version" applies to it, you have the option of following the terms and conditions either of that published version or of any later version published by the Free Software Foundation. If the Library as you received it does not specify a version number of the GNU Lesser General Public License, you may choose any version of the GNU Lesser General Public License ever published by the Free Software Foundation. If the Library as you received it specifies that a proxy can decide whether future versions of the GNU Lesser General Public License shall apply, that proxy's public statement of acceptance of any version is permanent authorization for you to choose that version for the Library.