Signedness of char is compiler-specific

Can someone explain how the signedness of char is platform specific?
http://stackoverflow.com/questions/1211982/can-someone-explain-how-the-signedness-of-char-is-platform-specific

Now for char. The standard doesn't say which of those two interpretations should be correct.

(..........)

Some compilers offer a command-line switch to control which one it will be. Some compilers have different defaults depending on what OS they're running on, so they can match the OS convention.

In most code, it really shouldn't matter. They are treated as three distinct types, for the purposes of overloading. Pointers to one of those types aren't compatible with pointers to another type. Type calling strlen with a signed char* or an unsigned char*; it won't work.

Use signed char when you want a one-byte signed numeric type, and use unsigned char when you want an one-byte unsigned numeric type. Use plain old char when you want to hold characters.

(..........)

It's more correct to say that it's compiler-specific and you should not count on char being signed or unsigned when using char without a signed or unsigned qualifier.

Otherwise you would face the following problem: you write and debug the program assuming that char is signed by default and then it is recompiled with a compiler assuming otherwise and the program behaviour changes drastically. If you rely on this assumption only once in a while in your code you risk facing unintended behaviour in some cases which are only triggered in your program under specific conditions and are very hard to detect and debug.

BUSYBOX - Frequently Asked Questions - Portability
http://www.busybox.net/FAQ.html#portability

On a related note, we made the "default signedness of char varies" problem go away by feeding the compiler -funsigned-char. This gives us consistent behavior on all platforms, and defaults to 8-bit clean text processing (which gets us halfway to UTF-8 support).