Re: Ryu floating point output patch

Поиск
Список
Период
Сортировка
От Andrew Gierth
Тема Re: Ryu floating point output patch
Дата
Msg-id 87d0nqjd5b.fsf@news-spur.riddles.org.uk
обсуждение исходный текст
Ответ на Re: Ryu floating point output patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Ryu floating point output patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:

 Tom>     result[sign] = '0';

 Tom> IMO, this is just awful coding, using a "bool" argument in just
 Tom> one place as a boolean and in four other ones as an integer. Aside
 Tom> from being cowboy coding, this has very serious risks of
 Tom> misbehaving on platforms where "bool" isn't C99-like, so that
 Tom> "sign" could potentially have values other than 0 and 1.

Elsewhere in the code it relies fairly heavily on the result of boolean
expressions being exactly 0 or 1 (which I'm pretty sure is required in
C89, not just C99); the only two places in the upstream that actually
required C99-specific boolean semantics were fixed in da6520be7.

Obviously I'll fix the warning, but how strict do you want to be about
the rest of the code? There are a lot of examples of things like,

    const uint32 q = log10Pow5(-e2) - (-e2 > 1);

    output = vr + (vr == vm || roundUp);

The code as it stands now follows the rule that nothing is ever assigned
to a "bool" variable, parameter, or result except the result of a
logical expression; and given that, that the value of any "bool"
variable interpreted as an integer is 0 or 1 and no other value.

-- 
Andrew (irc:RhodiumToad)


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

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: CPU costs of random_zipfian in pgbench
Следующее
От: Justin Pryzby
Дата:
Сообщение: Re: REL_11_STABLE: dsm.c - cannot unpin a segment that is not pinned