Page 1 of 1

bug in pow_hh.c & pow_ii.c

PostPosted: Thu Jun 17, 2010 9:05 am
by allez_zyva
Hi,

I'm new to CLAPACK so please forgive me if this has already been reported.

I am rebuilding (3.1.1-VisualStudio merged with 3.2.1) on Visual Studio 2008 and got 2 warnings (among "a few" others...)
f2clibs\libf2c\pow_ii.c(22) : warning C4723: potential divide by 0
f2clibs\libf2c\pow_hh.c(22) : warning C4723: potential divide by 0
the offending code in both file is
return x == 0 ? 1/x : 0;
and it should be
return x != 0 ? 1/x : 0;

Rather clever compiler, isn't it ?

James

Re: bug in pow_hh.c & pow_ii.c

PostPosted: Sun Jul 04, 2010 7:50 pm
by HarryWright
Hi guys, I'm having the same problem as the OP, and i noticed nobody replied.

Any solutions?

Harry.

Re: bug in pow_hh.c & pow_ii.c

PostPosted: Mon Jul 12, 2010 11:41 pm
by cottrell
Well, what would you say is the correct answer to the problem
"zero to the nth power", for n <= 0? Some might say that zero
to any power ought to give zero, but others would say the result
is undefined, and that is apparently the view taken by the authors
of libf2c: they are deliberately provoking an exception when you
try to take zero to a non-positive power.

This is illustrated by the following simple C program: It runs OK as
written, but provokes a floating point exception if you get rid of
the special treatment of 0^j, j <= 0. If you disagree with the libf2c
authors on this point, you'll have to write your own pow_ii.

Code: Select all
#include <stdio.h>

int main (void)
{
    int i, j;

    for (i=-4; i<=4; i++) {
        for (j=-2; j<=2; j++) {
            printf("Trying %d to the %d power\n", i, j);
            if (i == 0 && j <= 0) {
                printf("Out of bounds\n");
            } else {
                printf("pow_ii(%d, %d) = %d\n", i, j, pow_ii(&i, &j));
            }
        }
    }

    return 0;
}

}

Re: bug in pow_hh.c & pow_ii.c

PostPosted: Tue Jul 13, 2010 8:43 am
by cottrell
Correction to my last post: the algorithm in pow_ii.c permits
0 to the power 0 and gives the answer 1 (which is certainly
defensible but not universally accepted). It generates division
by zero only when the first argument is zero and the exponent
is negative -- which is pretty hard to disagree with!

@James: your compiler is only fairly clever: it correctly
detects the possibility of division by zero but (naturally)
doesn't understand what that line of code is doing.