Re: ctype(3), again

[Valery Ushakov <uwe%stderr.spb.ru@localhost>]

On Mon, Jan 14, 2019 at 16:30:23 +0100, Martin Husemann wrote:

> On Mon, Jan 14, 2019 at 03:44:32PM +0100, Thomas Klausner wrote:
>
> > The standard workaround is to cast arguments to (unsigned char). I've
> > provided patches for gnucash for that, but they received pushback
> > because the compiler shouldn't error out on this undefined behaviour.
> > (gnucash upstream is happy with it dumping core at runtime)
> > 
> > Here's the bug report with more details.
> > 
> > https://bugs.gnucash.org/show_bug.cgi?id=797039
> 
> Our code is explicitly *trying* to enforce this warning, see the CAVEATS
> section in ctype(3).

Exactly.  And replying to wiz - this is not a "workaround", is it?
The cast to unsigned char ensures that the requirement

  "the argument is an int, the value of which shall be representable
  as an unsigned char ..."

is satisfied for a char argument (that cannot be "equal the value of
the macro EOF").

On NetBSD one can compile with -D_CTYPE_NOINLINE to get ctype
functions defined as functions.  In that case tolower(*s) call will
not be warned about but the behavior is undefined as *s is a negative
char value.

I.e. tolower((unsigned char)*s) is correct usage according to the
standard and with the macro definition the compiler sees the indexing
and can warn about the missing cast.  With tolower as a function the
compiler cannot warn about the missing cast, but it doesn't change the
meaning/corectness of the code.

-uwe