[Fontconfig] clang warnings when building fontconfig git head

Thomas Klausner wiz at netbsd.org
Thu Jun 27 23:42:34 PDT 2013


On Fri, Jun 28, 2013 at 03:32:42PM +0900, Akira TAGOH wrote:
> On Wed, Jun 26, 2013 at 12:15 AM, Thomas Klausner <wiz at netbsd.org> wrote:
> > And a few warnings because the is* macros on NetBSD only accept EOF or
> > unsigned char. These are usually fixed by adding casts, i.e.
> > "isspace((unsigned char)foo)".
> >
> >   GEN      fc-case
> > fc-case.c:217:10: warning: array subscript is of type 'char' [-Wchar-subscripts]
> >     if (!isxdigit (line[0]))
> >          ^~~~~~~~~~~~~~~~~~
> > /usr/include/sys/ctype_inline.h:58:45: note: expanded from macro 'isxdigit'
> > #define isxdigit(c)     ((int)((_ctype_tab_ + 1)[(c)] & _CTYPE_X))
> >                                                 ^~~~
> > 1 warning generated.
> 
> shouldn't this issue be rather fixed in macro to deal with the
> subscript as integer because of C99 and POSIX spec?

Here's a part of the isdigit man page by the Open Group for IEEE Std
1003.1, 2013 Edition:

"The c argument is an int, the value of which the application shall
ensure is a character representable as an unsigned char or equal to
the value of the macro EOF. If the argument has any other value, the
behavior is undefined."

http://pubs.opengroup.org/onlinepubs/9699919799/functions/isdigit.html

In C99, AFAICT, the sentence is quite similar: "In all cases the
argument is an int, the value of which shall be representable as an
unsigned char or shall equal the value of the macro EOF. If the
argument has any other value, the behavior is undefined."

Here's a part of from ctype(3) on NetBSD:

CAVEATS
     The first 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.  The result
     should then be cast to int to avoid warnings from some compilers.
     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).

http://netbsd.gw.com/cgi-bin/man-cgi?ctype++NetBSD-current


Cheers,
 Thomas


More information about the Fontconfig mailing list