compiling app with unsigned char breaks wx/mimetype.h in 2.8.0rc1

[Alicia da Conceicao]

>  While this could be fixed/worked around in wx/mimetype.h itself, I think
> the real problem is that you can't write "s + c" where s if of type
> wxString and c is a char. We probably need to provide additional operator+
> overloads for unsigned char to really fix this. Any patches in this
> direction (especially tested on all 3 platforms) would be appreciated.

Hi VZ:

Thanks for your quick response.  I would be happy to test any patches
on wxMSW, wxWince, wxMac, & wxGTK.

>> Is there any reason why unsigned-char support for user applications was
>> broken in 2.8.0rc1?
> The obvious answer is that nobody uses unsigned char, clearly it wasn't
> broken on purpose.

Western European languages other than English make extensive use of the
the extended ASCII character set (0xA0-0xFF) for accented characters as
specified in the ISO-8859-1 standard:

http://en.wikipedia.org/wiki/Iso_8859-1
http://www.utoronto.ca/webdocs/HTMLdocs/NewHTML/iso_table.html

It does not make sense to have negative character values, since ISO-8858-1
values are non-negative integers from 0 to 255.  Even newer text encoding
formats such as 16 bit and 32 bit Unicode, do not have any concept of
negative characters.

The idea of using signed characters started and in the US and promoted
in other English speaking countries, as an abbreviation for 8 bit integers.
But the developers who specified the ISO-8859 standards and write non-
English applications often used unsigned-char.  That is why the unsigned-
char is an option is every modern "C" compiler.

Alicia.