Seems at some point someone decided not to be machine-independent in
backend/utils/adt/float.c

Redhat 5.2 system with gcc 2.8.1 doesn't define NAN unless _GNU_SOURCE is
defined first. Although include/utils/dt.h *does* check for NAN (and HUGE_VAL)
before using them, the float.c doesn't.

What happened?

Taral

Fri, 15 Jan 1999 23:27:41 -0600
Taral <taral@cyberjunkie.com>
backend/utils/adt/float.c uses non-existent NAN value
> Seems at some point someone decided not to be machine-independent in
> backend/utils/adt/float.c
> 
> Redhat 5.2 system with gcc 2.8.1 doesn't define NAN unless _GNU_SOURCE is
> defined first. Although include/utils/dt.h *does* check for NAN (and HUGE_VAL)
> before using them, the float.c doesn't.
> 
> What happened?

I don't see NAN used in any file except numberic.c.  I don't see it in
float.c, at least in 6.5.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Sat, 16 Jan 1999 00:40:20 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] backend/utils/adt/float.c uses non-existent NAN value
>
> Seems at some point someone decided not to be machine-independent in
> backend/utils/adt/float.c
>
> Redhat 5.2 system with gcc 2.8.1 doesn't define NAN unless _GNU_SOURCE is
> defined first. Although include/utils/dt.h *does* check for NAN (and HUGE_VAL)
> before using them, the float.c doesn't.
>
> What happened?

    Don't know exactly - but

    the new NUMERIC data type started recently a discussion about
    NAN, because I tried  to  be  able  to  convert  NAN  from/to
    float's, and that started some trouble. I'm not sure how this
    went into adt/float.c. At least I think we should fix all the
    NAN handling for v6.5.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #



Mon, 18 Jan 1999 09:36:10 +0100 (MET)
jwieck@debis.com (Jan Wieck)
Re: [HACKERS] backend/utils/adt/float.c uses non-existent NAN value
> >
> > Seems at some point someone decided not to be machine-independent in
> > backend/utils/adt/float.c
> >
> > Redhat 5.2 system with gcc 2.8.1 doesn't define NAN unless _GNU_SOURCE is
> > defined first. Although include/utils/dt.h *does* check for NAN (and HUGE_VAL)
> > before using them, the float.c doesn't.
> >
> > What happened?
> 
>     Don't know exactly - but
> 
>     the new NUMERIC data type started recently a discussion about
>     NAN, because I tried  to  be  able  to  convert  NAN  from/to
>     float's, and that started some trouble. I'm not sure how this
>     went into adt/float.c. At least I think we should fix all the
>     NAN handling for v6.5.
> 

I fixed that.  Added the NAN define from numeric.c.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Mon, 18 Jan 1999 07:27:48 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] backend/utils/adt/float.c uses non-existent NAN value
> > Seems at some point someone decided not to be machine-independent in
> > backend/utils/adt/float.c

That was me.

> > Redhat 5.2 system with gcc 2.8.1 doesn't define NAN unless 
> > _GNU_SOURCE is defined first. Although include/utils/dt.h *does* 
> > check for NAN (and HUGE_VAL) before using them, the float.c doesn't.
> > What happened?
>     the new NUMERIC data type started recently a discussion about
>     NAN, because I tried  to  be  able  to  convert  NAN  from/to
>     float's, and that started some trouble. I'm not sure how this
>     went into adt/float.c. At least I think we should fix all the
>     NAN handling for v6.5.

Jan started with NAN handling for numeric, and I'd already done the same
thing for the date/time types quite a while ago. We also had a
discussion recently that we should be handling 'NaN' and 'Infinity' on
float8 input values so that dump/reload is more robust and symmetric, so
I added that in ('-Infinity' still needs to be done).

I added in the new code, knowing that there was some fixup and
consolidation which needs to be done. Unless someone has worked out
another scheme, I'd suggest using the date/time code in dt.h as an
example to work from. We might want to use PG_NAN and PG_INFINITY, which
we can then define in one central place.

If someone want to work this out, I'd be happy to use the result. Or I
can do something directly. I'd like a solution with the equivalent of
NAN and HUGE_VAL (and -HUGE_VAL). Jan? Taral?

                    - Tom

Mon, 18 Jan 1999 14:33:17 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] backend/utils/adt/float.c uses non-existent NAN value
On Mon, 18 Jan 1999, you wrote:
>If someone want to work this out, I'd be happy to use the result. Or I
>can do something directly. I'd like a solution with the equivalent of
>NAN and HUGE_VAL (and -HUGE_VAL). Jan? Taral?

Doesn't dt.h have some replacements for NAN and HUGE_VAL? Something like that?
Couldn't we use those?

Aha... DT_INVALID is the generic NAN, and DT_NOBEGIN/DT_NOEND are the generic
HUGE_VAL and -HUGE_VAL...

Taral

Mon, 18 Jan 1999 13:26:08 -0600
Taral <taral@cyberjunkie.com>
Re: [HACKERS] backend/utils/adt/float.c uses non-existent NAN value
unsubscribe


Tue, 19 Jan 1999 09:41:29 +0700
Puchong <puchong.h@cdg.co.th>
(no subject)