Re: Ryu floating point output patch - Mailing list pgsql-hackers

From Donald Dong
Subject Re: Ryu floating point output patch
Date
Msg-id 5EF66A1A-B897-452C-B3B0-EF7DC3761106@csumb.edu
Whole thread Raw
In response to Re: Ryu floating point output patch  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Responses Re: Ryu floating point output patch  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Re: Ryu floating point output patch  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
List pgsql-hackers
> On Jan 15, 2019, at 2:37 AM, Andrew Gierth <andrew@tao11.riddles.org.uk> wrote:
>
> Andres> strtod()'s job ought to computationally be significantly easier
> Andres> than the other way round, no? And if there's buggy strtod()
> Andres> implementations out there, why would they be guaranteed to do
> Andres> the correct thing with our current output, but not with ryu's?
>
> Funny thing: I've been devoting considerable effort to testing this, and
> the one failure mode I've found is very interesting; it's not a problem
> with strtod(), in fact it's a bug in our float4in caused by _misuse_ of
> strtod().

Hi,

I'm trying to reproduce the results by calling float4in in my test code. But I
have some difficulties linking the code:

testfloat4.c:(.text+0x34): undefined reference to `float4in'
testfloat4.c:(.text+0x3c): undefined reference to `DirectFunctionCall1Coll'

I tried offering float.o to the linker in addition to my test program. I also
tried to link all the objects (*.o). But the errors still exist. I attached my
changes as a patch.

I wonder if creating separated test programs is a good way of testing the code,
and I'm interested in learning what I missed.

Thank you.


Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: PSA: we lack TAP test coverage on NetBSD and OpenBSD
Next
From: Michael Paquier
Date:
Subject: Re: [HACKERS] REINDEX CONCURRENTLY 2.0