signed |
unsigned |
#include <stdio.h> int main() { char cNum; short sNum; int iNum
char = -1 short = -1 int = -1
printf("cNum[%d], sNum[%d], iNum[%d]\n", cNum, sNum, iNum); sNum = cNum; printf("cNum[%d], sNum[%d], iNum[%d]\n", cNum, sNum, iNum);
returm 0; } 값 c -1 s -1 i -1 -1 -1 -1 |
#include <stdio.h> int main() { unsigned char cNum; unsigned short sNum; unsigned int iNum
char = -1 short = -1 int = -1
printf("cNum[%d], sNum[%d], iNum[%d]\n", cNum, sNum, iNum); sNum = cNum; printf("cNum[%d], sNum[%d], iNum[%d]\n", cNum, sNum, iNum);
returm 0; } 값 c 255 s 65535 i -1 255 255 -1 |
문제1) unsigned int -1일 때 가장 큰수가 아닌 -1일 출력이 되는가?
정확하게 해결이 되지 않아 가설을 세워 보았습니다
1. 가설 : 최대 2바이트 16비트 구성이기 때문에 int형일 경우 최상단 한자리가 기호를 표현해야 되니 최대값을 표현을 할수 없게 되어서
원래 최대값은
1111 1111 1111 1111 1111 1111 1111 1111 - 4294967295 이렇게 나온다.
16비트 구성시 기호자를 뺀 나머기 자리로 최대값을 만들면
0111 1111 1111 1111 1111 1111 1111 1111 - 2147483647 절반정도 되는 값이 최대값이 된다. 이는 제대로 된 최대값을 구할 수가 없는 것이다.
char short의 경우에는 앞에 여유 비트가 있어서 정상적으로 출력가능
(short)
1000 0000 0000 0000 1111 1111 1111 1111
음양 기호자리
%u를 사용하면 정상적으로 출력하는 것으로 보아서 %u의 기능은 다음 비트를 이용하여 계산이 가능한 명령인 것으로 유추를 해본다
+추가
그렇다면 모든 음수는 모두 제대로 표현이 되지 않는가?
int를
-4294967296를 넣으면 0이라는 값이 출력된다
-4294967295를 넣으면 1이라는 값이 출력된다
-4294967294를 넣으면 2이라는 값이 출력된다
-4294967295가 1이 되는 이유는
0111 1111 1111 1111 1111 1111 1111 1111
그다음 비트에서
0000 0000 0000 0000 0000 0000 0000 0001로 계산이 되기 때문에 1이라는 값이 나오게 된다.
위 결과를 보아 비트단위 안에서의 값만으로 계산되어지는 것을 확인할 수 있다.
즉 비트 2개를 묶어서 하나의 값으로 출력을 하지 못하는 것 같다.
2)가설 : 프로그램밍 언어중 int 가장 나중에 개발되어져서 표현이 않된다.
-sign과 unsign이 개발될 시기에 16비트의 단위로된 회로가 없어서 명령이 8비트까지만 적용이 되도록 개발이 되어서 16비트인 int %d로 출력이 되지 않는다. 그래서 %u인 새로운 명령을 쳐야지만 최대값이 출력이 가능하다.
문제2) sNum = cNum signed 과 unsigned의 출력문제
참고
signed는 만약에 1바이트를 지정한다면 -125~+125를 지정할수 있다
unsigned는 만약에 1바이트를 지정한다면 0~+255를 지정할수 있다
signed에서는 기호를 포한만 -1 +1 출력이 가능해서 sNum = cNum이라고 입력하면
그대로 -1 -1인 값이 출력이 되고
unsigned에서는 -1일 경우 최대값을 출력하게 되는데 cNum = 255 sNum = 65535가 출력이 되지만 sNum = cNum이라고 입력하면 255로는 값은 sNum의 값중에 있기 때문에 sNum은 그대로 255로 출력이 된다
[현재상태] - 고민중
'Embeded C > Q&A' 카테고리의 다른 글
gcc와 cl 그리고 중간단계별 compile(컴파일) (0) | 2011.03.28 |
---|