문자값을 정수로 비교할때는 unsigned char를 사용해야 한다.

int
func(char *string)
{
if(string[0] == 0x20 || string[1] <= 0x10) {
....

여기서 string은 signed char이기 때문에 만약 string[1]의 값이 127보다 크면(확장 아스키코드) 음수로 인식되어서 if문이 참이 될 수 있다. 이럴땐 unsigned char로 string을 받아야지만 정상적으로 작동한다.

단지 문자열에서 문자를 복사/변환/제거 등(대부분의 문자열 연산)을 하는 경우에는 signed char를 사용해도 무방하다.

<추가>

아래는 http://kldp.org/node/75686 에서 전웅님의 댓글. 메모리에 접근해서 문자열을 다루는 함수들은 해당 문자열을 unsigned char로 다뤄야 하는 표준의 강제조항이 있다. 하지만 문자열을 가르키는 포인터를 모두 unsigned char로 할 필요는 없고, 단지 문자열을 다루는 함수에서는 반드시 unsigned char로 문자열을 해석해야 한다.

엉뚱한 방향으로 흘러가던 논의가 doldori 님 덕에 제자리를 찾았군요.

unsigned char 는 모든 bit 를 투명하게 볼 수 있는 특성을 제공합니다.
즉, 다른 type 은 내부 비트의 일부를 값을 표현하기 위한 용도가 아닌
다른 용도로 사용할 수 있으나 unsigned char 는 이것이 허락되지
않습니다.

따라서, 임의의 메모리에 바이트 단위로 접근해 값을 다룰 때에는 반드시
unsigned char 를 사용해야 full portability 를 얻을 수 있는 것입니다.
또한, 그와 같은 이유로 signed char 가 표현할 수 있는 값의 개수보다
unsigned char 가 표현할 수 있는 값의 개수가 많다는 사실에도 유의할
필요가 있습니다. signed char unsigned char 사이의 값 변환이 1:1
로 이루어질 수 "없는" 경우도 있음을 의미합니다.

이와 같은 이유로, 표준이 바이트 값에 접근해야 하는 경우나 문자에
접근해야 하는 경우 (예: mem*(), str*() 함수들) 에는 모두 unsigned char
로 접근하도록 요구하고 있습니다. 책에서는 memcpy 함수를 흉내내는
것이기 때문에 그런 사항을 반영해 unsigned char 를 사용했습니다.

예전에 이곳에서도 비슷한 논의가 있었던 것으로 기억합니다만, 꼭 padding
bit 가 아니어도 null character 의 정의에 의해 문제가 될 수 있는 경우가
있습니다. signed char 는 1s' complement 표현이나 sign-magnitude
표현에서 -0 을 가질 수도 있습니다 - 이 경우 sign bit 가 1 이 됩니다.
하지만, null character 의 정의는 (sign bit 포함해) 모든 비트가 0 이길
요구하고 있습니다. 즉, -0 은 null character 가 될 수 없는 것입니다.
따라서 이를 올바르게 구분해내기 위해서는 unsigned char 로 접근해야
하는 것입니다.

p.s. 제 기억으로는 최소한 padding bit 에 대한 내용, unsigned char 가
padding bit 를 갖지 않는다는 내용은 책에서 다룬 것으로
기억합니다만...

Superkkt Blog