Re: draft patch for strtof()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: draft patch for strtof()
Date: 2019-01-16 16:07:26
Message-ID: 8254.1547654846@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Tom> The errno handling in strtof seems bizarrely overcomplex; why do
> Tom> you need the separate caller_errno variable?

> Eh. I was preserving the conventional behaviour of setting errno only on
> errors and not resetting it to 0,

Oh, I see. -ENOCAFFEINE.

> but I suppose you could argue that
> that is overkill given that the function is called only in one place
> that's supposed to have already set errno to 0.

Well, we probably oughtta endeavor to maintain compatibility with
the function's standard behavior, because other calls to it are
likely to creep in over time. Objection withdrawn.

> Tom> I'm not that much on board with introducing test cases that we
> Tom> know, beyond question, are going to be portability headaches. What
> Tom> will we actually gain with this, compared to just not having the
> Tom> test case?

> The purpose of the test case is to ensure that we're getting the right
> values on input. If these values fail on any platform that anyone
> actually cares about, then I think we need to know about it.

Meh. I think the actual outcome will be that we define any platform
that gets the wrong answer as one that we don't care about, mainly
because we won't have any practical way to fix it. That being the
situation, trying to maintain a test case seems like pointless
make-work.

(FWIW, I'm running the patch on gaur's host, just to confirm it
does what you expect. Should have an answer in an hour or so ...)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2019-01-16 16:08:09 Re: What to name the current heap after pluggable storage / what to rename?
Previous Message Robert Haas 2019-01-16 16:02:48 Re: Making WAL receiver startup rely on GUC context for primary_conninfo and primary_slot_name