Re: Thread-unsafe coding in ecpg

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Thread-unsafe coding in ecpg
Дата
Msg-id 27121.1547949637@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Thread-unsafe coding in ecpg  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Список pgsql-hackers
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> Would it help if we had non-locale-aware functions for both
> floating-point output _and_ input? i.e. import a known-working strtod()
> (allowing us to remove all the hacks that have grown up around it, for
> special-case input and wonky error handling) with locale functionality
> removed.

Dunno, is there such a thing as a platform-independent strtod()?
I'd have thought that, for instance, typical implementations would
be pretty much in bed with the details of IEEE float format ---
your example where strtof() is different from (float) strtod()
makes it hard to believe that it can be written without assumptions
about the hardware's float format.

(Note that this concern is independent of whether we adopt the Ryu
code, which IIUC also depends on IEEE floats.  Our answer for anyone
wanting to run on non-IEEE hardware can be to #ifdef out Ryu and use
the existing float output code.  But doing the equivalent thing on the
input side wouldn't solve ecpg's problem.)

            regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Changing SQL Inlining Behaviour (or...?)
Следующее
От: Andrew Gierth
Дата:
Сообщение: Re: Ryu floating point output patch