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

[Patrick Alken]

Thanks Hal, this fix is now in the repository

On 03/28/2015 10:54 AM, Hal Finkel wrote:
> 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