From 0d7a5bb212b2c2bc3e3727873c0646a347cb4469 Mon Sep 17 00:00:00 2001 From: vlefevre Date: Thu, 22 Nov 2018 09:27:09 +0000 Subject: [doc/README.dev] Update about issues with mixing signed/unsigned types. git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13281 280ebfd0-de03-0410-8827-d642c229c3f4 --- doc/README.dev | 31 +++++++++++++++++++++---------- 1 file changed, 21 insertions(+), 10 deletions(-) (limited to 'doc') diff --git a/doc/README.dev b/doc/README.dev index e07f6f316..9e5ca3bc2 100644 --- a/doc/README.dev +++ b/doc/README.dev @@ -1132,25 +1132,36 @@ 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 will probably be incorrect. With MPFR 2.x, this problem could +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 is OK, -but on ILP32, 32-bit int + 32-bit unsigned long is incorrect), 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). +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 locally avoid integer overflow. +array of bits (e.g. for limbs) and to temporarily avoid integer overflow. =========================================================================== -- cgit v1.2.1