Hello Noah, On Tue, Sep 17, 2019 at 11:07:21PM -0700, Noah Misch wrote:
> > I've finally had some time to look into this. The NetBSD as well as > > glibc implementations of strtod() are huge. Duplicating them in DBD::Pg > > just for this single call would be a nightmare IMO. > That is unfortunate. How huge? The NetBSD implementation itself is about 24KiB but isn't self-contained. It depends to an unknown extent on a whole floating point library gdtoa: # du -sb src/lib/libc/gdtoa/strtod.c 23576 src/lib/libc/gdtoa/strtod.c # wc -l src/lib/libc/gdtoa/strtod.c 1117 src/lib/libc/gdtoa/strtod.c # du -sk src/lib/libc/gdtoa 1004 src/lib/libc/gdtoa # wc -l src/lib/libc/gdtoa/*.[ch] [...] 11107 total Separating it out of that would be a medium-sized trial-and-error project potentially introducing new bugs. And each change removing a dependency would incur additional syncing effort in the future - assuming that this library isn't totally bug-free and gets updates. cvs log says that it's been quite stable since 2014 but there were some updates this year. The glibc implementation is twice the size but may be a bit more self-contained (just a feeling based on a blog post I read about it) - but has its licensing issue. > > I did however stumble across strtod_l() which takes a locale as a third > > argument. > That function is not portable enough: > https://www.gnu.org/software/gnulib/manual/html_node/strtod_005fl.html Found that as well and wanted to check how gnulib implements replacements on those systems. But it simply doesn't. Duh. On Wed, Sep 18, 2019 at 09:52:03AM -0500, David Christensen wrote: > > That function is not portable enough: > > https://www.gnu.org/software/gnulib/manual/html_node/strtod_005fl.html > This code claims to be in the public domain; no idea if it’s any good, but > looks like a reasonable size at least: > https://gist.github.com/mattn/1890186 There's a comment from end of last year pointing out misbehaviour on a specific input format. OTOH: If we can be *really* certain about the format generated by Postgres we might be able to get away with a very reduced version of strtod_l(). A generic implementation deals with a number of different formats such as 1.2e12, 0x prefix for hex base, infinity, nan and so on which postgres might never generate. I'm really starting to wonder if solving a problem that's already been solved by perl itself is worth the effort. If only Apple were to update their system perl once every five years or so we'd be golden. -- Thanks, Michael
