[ccan] Testing ccanlint on Cygwin (gcc 4.3.4-3)

[Sam Watkins]

>  * ctype.h functions (islower, toupper, etc.) result in array
> subscript warnings, treated as errors, when passed chars.  What else
> would you pass them?

> Weird.  But such warnigns are not fatal, so I don't think we should be
> working around them in CCAN in general.

It becomes fatal when you pass them signed chars having values less than -1.
A plain 'char' may be signed or unsigned depending on the architecture.

You must not pass a plain char directly to islower() and friends.  The
functions take int arguments, having the value of an _unsigned_ char, or EOF
(typically -1).

 From the Linux islower() ... manpage:
 "These functions check whether c, which must have the value of an unsigned char or EOF ..."

Correct usage might be:
	char c = 'c';
	int lc = islower((unsigned char)c);
or:
	int c = getc();
	int lc = islower(c);

i.e. you must pass them an unsigned char or (int)(unsigned char)c, like you get
back from getc() etc.

You wouldn't want islower() to be indexing its array with a signed char!

> I would imagine that someone would end up putting a hack in config.h for
> this kind of local disaster.

It's not a local disaster.

> The second introduces a header called compat.h which, if newlib is present,
> wraps ctype.h functions and makes ssize_t available.  It then includes
> "compat.h" at the top of several source and header files.

It sounds to me like the ccan modules are using ctype.h functions incorrectly,
and mingw is kindly letting you know.  That should be fixed in ccan not with a
wrapper.

It would be nice if gcc --pedantic -Wall -Wextra would warn about this (on
Linux too), but it doesn't appear to do so.

Sam