>> BUT - for compiler '\355' equals to -19, so the macro looks truly
>> like this:

>> ((_ctype_ + 1)[-19] & (_P|_U|_L|_N|_B))
>>              ^^^^^^^^

I've seen ctype setups that do something like

char __ctype_[384] = { ... }
#define _ctype_ (__ctype_+128)

specifically to accommodate using either signed or unsigned char
arguments.  We may want to do something similar, though I _think_ the
ctype functions are not defined if the argument is other than an
unsigned char cast to int, or EOF.

> I think we should follow Peter Seebachs advice and make char unsigned
> by default to eliminate the casts.

I don't; I think this is a bad idea.  I think we should leave it as we
have it, with each port choosing whether chars are signed or unsigned
by default, preferably with at least one port choosing each option (to
catch bugs depending on one option or the other).

> This would help a lot with other software as well, like X and its
> bitmaps...

If X really needs unsigned chars, then build it with -funsigned-char
(and send in a bug report to the X people - something like X should
always be declaring chars explicitly signed or unsigned whenever it
cares).

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B