Re: Ryu floating point output patch - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Ryu floating point output patch
Date
Msg-id 8224.1550443439@sss.pgh.pa.us
Whole thread Raw
In response to Re: Ryu floating point output patch  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Responses Re: Ryu floating point output patch  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Re: Ryu floating point output patch  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
List pgsql-hackers
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
>  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

Ugh.

> (which I'm pretty sure is required in C89, not just C99);

For truth-valued expressions, yes.  The question here is what can be
assumed about the integer value of a variable declared to be type "bool",
a question C89 does not address.

> Obviously I'll fix the warning, but how strict do you want to be about
> the rest of the code?

Well, given that we're now requiring C99 compilers, you'd think that
assuming stdbool semantics would be all right.  The problem on prairiedog
and locust (which seem to be the only complainants) is that stdbool
provides a _Bool type that has size 4, so c.h decides not to use stdbool:

#if defined(HAVE_STDBOOL_H) && SIZEOF_BOOL == 1
#include <stdbool.h>
#define USE_STDBOOL 1
#else

#ifndef bool
typedef char bool;
#endif

I believe that we could suppress these warnings by changing that last
to be

typedef unsigned char bool;

since what these warnings are really on about is the uncertain signedness
of the type "char".  Perhaps that's a reasonable way to deal with it.
If 0/1 assumptions are all over the place in the Ryu code, avoiding them
in this one place isn't going to move the goalposts for portability.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: CPU costs of random_zipfian in pgbench
Next
From: Andrew Dunstan
Date:
Subject: Re: Ryu floating point output patch