[tz] Dubious coding in tzcode 2019b

[Clive D.W. Feather]

Paul Eggert said:
> The unusual case cannot happen in any compiler conforming to C89 or later, 
> because private.h does this:
> 
> #if HAVE_STDBOOL_H
> # include <stdbool.h>
> #else
> # define true 1
> # define false 0
> # define bool int
> #endif

Hmm, I would have:

  typedef int bool;

to stop someone writing "unsigned bool".

Also, that definition is going to cause problems if you have "bool q : 1"
within a structure; you need it to be unsigned.

>> I think I would write it as:
>> 
>>      thistimecnt = - (ptrdiff_t) (locut + hicut);
>> 
>> because that shows the intent better.
> I would rather avoid unnecessary casts, so the attached proposed patch does it 
> the way you suggest except without the cast.

Your call; I think the cast helps in this case.

> I'm not worried about the style issue of treating true and false as 1 and 0, as 
> the idiom should be reasonably obvious to readers who know C.

Ah, my code either has:

    enum { false, true };

or:

    #define false (0 == 1)
    #define true (!true)

or, when I'm in a whimiscal mood:

    #define true  ('/'/'/')
    #define false ('-'-'-')

> (Anybody who's 
> been around long enough to remember C's predecessor BCPL where true was 
> all-bits-1,

Oh no it wasn't.

TRUE and FALSE were implementation-defined values. The only requirement was
that the bitwise operators such as & and NEQV gave the correct results when
applied to them. So, for example, it would be legitimate for TRUE to be 7
and FALSE to be 3, with logical mode testing the 4 bit.

-- 
Clive D.W. Feather          | If you lie to the compiler,
Email: clive at davros.org     | it will get its revenge.
Web: http://www.davros.org  |   - Henry Spencer
Mobile: +44 7973 377646