Re: Ryu floating point output patch

Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)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