On Dec 20, 10:20am, "Martin Husemann" wrote:
} Subject: RE: `char -> unsigned char'
} > Instead of casting, it may be cleaner to declare the relevant variables
} > unsigned.  <stdio.h> also uses unsigned chars.  Alas, <string.h> uses
} > signed chars.  So much for consistency.
} 
} Both would be violating the ANSI C library specs, but the code is a little
} bit more subtle: the exported function prototypes have to use "char *" and
} "const char *" as mandated by the ANSI spec, which does neither qualify as
} "signed" nor "unsigned". Then there are declarations internal to our
} implementation of stdio (i.e. in struct __sFILE) which are completely
} private to our implementation and can use what they like.

What I meant by my comments about <stdio.h> is that the character values
returned by things like getchar() are in the range of values that are
held by an unsigned char (though you need to first store the return value
in an int so that you can check for EOF).

} In string.h there are only (ANSI mandated) function prototypes, which don't
} qualify signed or unsigned (so you are wrong: string.h doesn't use signed
} chars, it uses machine dependend chars, they are signed on the i386, but
} unsigned on the powerpc, IIRC).

Yeah, I knew that and stated it incorrectly.  It's just a shame that
ANSI didn't promise that "machine dependent" characters would give defined
behaviour when passed to the <ctype.h> functions, since these characters
are supposed to be the most efficient of the two possibilities.

} obviously could chose to declare "unsigned char *" or "char *", whichever
} needs less casting or is the minimal change.

Yes.  I just wanted to point out that there was a possible alternative to
casting the argument to the <ctype.h> functions.  Not having looked at
the code, I don't know which would be the easiest change.