Thread: 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?

Taral

> 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,
Pennsylvania19026
 

>
> 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) #

> >
> > 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,
Pennsylvania19026
 

> > 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

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

unsubscribe