Re: BUG #2162: Same as bug #1679 - finite() - unresolved symbol

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-bugs(at)postgresql(dot)org, flconseil(at)yahoo(dot)fr
Subject: Re: BUG #2162: Same as bug #1679 - finite() - unresolved symbol
Date: 2006-01-12 19:28:26
Message-ID: 2266.1137094106@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Am Donnerstag, 12. Januar 2006 09:57 schrieb Tom Lane:
>> In principle an aggressive compiler could still determine that the
>> global variable is modified nowhere else in the executable.

> I think to do that the compiler would have to prove what the dynamic linker
> will do at run time.

Yeah. The idea of casting a function pointer to (double *) seems mighty
ugly, and in the absence of evidence that we need it, I think it's
better to stick with less surprising code. I've committed changes to
make the tests look like this:

AC_TRY_LINK([
#include <math.h>
double glob_double;
],
[return finite(glob_double) ? 0 : 1;],
[AC_DEFINE(HAVE_FINITE, 1, [Define to 1 if you have finite().])
AC_MSG_RESULT(yes)],
[AC_MSG_RESULT(no)])

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2006-01-12 19:54:24 Re: BUG #2166: attempted to update invisible tuple
Previous Message Jaime Casanova 2006-01-12 17:37:43 Re: BUG #2166: attempted to update invisible tuple