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
|
Список | 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 по дате отправления: