Re: Portability of strtod (was Re: pgsql: Include GUC's unit, if it has one, in out-of-range error message)

On Mon, Mar 11, 2019 at 8:45 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Michael Paquier <michael@paquier.xyz> writes:
> > On Sun, Mar 10, 2019 at 07:18:20PM +0000, Tom Lane wrote:
> I think what's going on here is what's mentioned in the comments in
> float8in_internal:
>
>          * C99 requires that strtod() accept NaN, [+-]Infinity, and [+-]Inf,
>          * but not all platforms support all of these (and some accept them
>          * but set ERANGE anyway...)
>
> Specifically, these symptoms would be explained if these platforms'
> strtod() sets ERANGE for infinity.
>
> I can think of three plausible responses.  In decreasing order of
> amount of work:
>
> 1. Decide that we'd better wrap strtod() with something that ensures
> platform-independent behavior for all our uses of strtod (and strtof?)
> rather than only float8in_internal.
>

This sounds like a good approach, but won't it has the risk of change
in behaviour?

> 2. Put in a hack in guc.c to make it ignore ERANGE as long as the result
> satisfies isinf().  This would ensure GUC cases would go through the
> value-out-of-range path rather than the syntax-error path.  We've got
> a bunch of other strtod() calls that are potentially subject to similar
> platform dependencies though ...
>

Yeah, this won't completely fix the symptom.

> 3. Decide this isn't worth avoiding platform dependencies for, and just
> take out the new regression test case.  I'd only put in that test on
> the spur of the moment anyway, so it's hard to argue that it's worth
> much.
>

For the time being option-3 sounds like a reasonable approach to fix
buildfarm failures and then later if we want to do some bigger surgery
based on option-1 or some other option, we can anyways do it.

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com