Re: [Bug-gsl] Undefined behavior in vector/test_source.c

[Hal Finkel]

Hi again,

Thanks for applying the patch. As it turns out, there is one more similar case 
in matrix/test_source.c. With this change (and a bug fix to LLVM, r233481), 
Clang can now compile gsl on big-Endian PPC64/Linux and pass make check.

Thanks again,
Hal

----- Original Message -----
> From: "Hal Finkel" <address@hidden>
> To: address@hidden
> Sent: Thursday, March 26, 2015 2:03:16 PM
> Subject: Undefined behavior in vector/test_source.c
> 
> Hello,
> 
> Currently, several of the tests in vector/test_source.c don't pass
> when compiled with Clang/LLVM on some targets because
> vector/test_source.c contains undefined behavior. I've attached a
> patch which corrects the problem, which is essentially this:
> 
>   if (FUNCTION (gsl_vector, get) (v, i) != (ATOMIC) (i*2.0))
> 
> The current code assumes that, when ATOMIC is unsigned char, for
> example, (unsigned char) (i*2.0) will have the same behavior as
> (unsigned char) (i*2), but it does not (the value is not guaranteed
> to wrap in the same way). The C standard says (6.3.1.4p1):
> 
> When a finite value of real floating type is converted to an integer
> type other than _Bool,
> 
> the fractional part is discarded (i.e., the value is truncated toward
> zero). If the value of
> 
> the integral part cannot be represented by the integer type, the
> behavior is undefined.
> 
> There are two problematic statements in this regard, and in the patch
> I've added some extra casts so that we're not doing an fp -> int
> conversion with an out-of-range integer.
> 
> Thanks in advance,
> Hal
> 
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

gsl-moreundef-fix.patch
Description: Text Data