Re: compiling linrad under NetBSD

[Martin Husemann <martin%duskware.de@localhost>]

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