2010-12-10 5 views
1

테스트 코드입니다. I386 GCC-4.4.5 gcc (v4.1.2 크로스 컴파일러) 정수 승격 문제

char ch = 0xff; 
int i = ch; 
printf("%d\n", i); 

, 출력은 -1. 그러나 powerpc-e300c3-linux-gnu-gcc-4.1.2 (MPC8315 크로스 컴파일러)에서 의 출력은 255입니다.

무엇이 잘못 되었나요? 왜 gcc-4.1.2 출력이 255입니까?

+1

이 문제도 발생했습니다. 'char'는 보통 "signed"이지만 PowerPC Linux에서는 서명이 없습니다. 이걸 발견했을 때 PowerPC에서 코딩 중이었고 다음 코드를 사용했습니다 :'unsigned char charflag [256]; ... charflag [c] & CF_WHITE'. 문제는'c'가 비 ASCII 버젼의 char 일 때,'char'가 서명 될 때 음의 인덱스가 생기는 것입니다. 해결책은'charflag [(unsigned char) c]'라고 말하면서 거짓 기호 확장을 막을 수 있었다. –

+2

255의 값을 char에 할당하는 것은 좋은 생각이 아닙니다. "그렇지 않으면 새로운 유형이 서명되고 그 값을 표현할 수 없으므로 결과가 구현 정의되거나 구현 정의 신호가 발생합니다. " 평범한'char'에 최대 127 개의 값을 저장할 수 있다고 가정 할 수 있습니다. 간단한 규칙으로 산술에 일반 문자 (char)를 사용하지 마십시오. –

답변

9

그것은 구현 정의 char 여부를 서명 또는 서명입니다 답변에 대한

감사합니다 ....

분명히 당신의 x86 컴파일러에 서명되어 있고 PowerPC 컴파일러에서 서명되지 않았습니다.

휴대 성을 위해 서명 여부에 관계없이 unsigned char 또는 signed char을 사용하십시오.

+1

GCC는'-signed-char' 플래그를 가지고있어서 모든 플랫폼에서'char'을 강제 서명합니다. 이것은 코드 포팅을위한 좋은 빠른 수정이지만, 여전히'char'의 signedness가 구현에 의해 정의 된 것을 보는 습관에 빠져 있어야합니다. –

+1

또는 변수의 크기에 대해 실제로 신경 쓰면 더 명확하게 명시하는 것이 좋습니다. stdint.h 헤더를 사용하십시오 (C99 이상). int8_t 및 uint8_t가 있습니다. 나는 정말로 '_'을 좋아하지 않지만. – Hexagon

+1

@Hex,'char'는 항상 1 바이트이며, 대다수의 현대 시스템에서는 8 비트입니다. 또한,'_t'없이 typedef를 만들 수 있습니다. –

관련 문제