On Tue, May 14, 2024 at 06:49:20PM -0400, Greg Troxel wrote:
rpi4-netbsd$ gmake xlinrad64
In file included from /usr/include/ctype.h:100,
from xmain.c:37:
xmain.c: In function ?main?:
xmain.c:220:14: error: array subscript has type ?char?
[-Werror=char-subscripts]
220 | i=toupper(s[0]);
This is a common bug. toupper is defined by C99 to take an int, and it
can be the valid range of characters or -1. I think we generally cast
to int.
No, it is important to cast to unsigned char. See "man ctype" and search for
CAVEATS:
The argument of these functions is of type int, but only a very
restricted subset of values are actually valid. The argument must either
be the value of the macro EOF (which has a negative value), or must be a
non-negative value within the range representable as unsigned char.
Passing invalid values leads to undefined behavior.
Values of type int that were returned by getc(3), fgetc(3), and similar
functions or macros are already in the correct range, and may be safely
passed to these ctype functions without any casts.
Values of type char or signed char must first be cast to unsigned char,
to ensure that the values are within the correct range. Casting a
negative-valued char or signed char directly to int will produce a
negative-valued int, which will be outside the range of allowed values
(unless it happens to be equal to EOF, but even that would not give the
desired result).
Because the bugs may manifest as silent misbehavior or as crashes only
when fed input outside the US-ASCII range, the NetBSD implementation of
the ctype functions is designed to elicit a compiler warning for code
that passes inputs of type char in order to flag code that may pass
negative values at runtime that would lead to undefined behavior:
Martin