세콤 없는 집에 불법으로 침입한 상황입니다.
strcpy라는게 기본적으로 몇칸짜리 배열인지 그런거는 관심없고 일단 포인터를 받아서 거기서부터 쭉 쓰고보는 함수라 에러가 안납니다.
만약 변수 두개를 연달아 선언해놓고, 저런 일이 벌어졌다면 뒤에 선언된 변수 내용이 희안하게 변해있는걸 목격할 수 있을겁니다

저기서 에러가 안 나주기 때문에, strncpy를 사용합니다. strncpy는 몇글자 제한 두고 카피하기 때문에 저런 문제가 일어나지 않습니다

꼭 그렇지는 않습니다. 컴파일러가 char s[6] 이라고 하게 되면 꼭 스택 프레임을 8 (4 byte align) 바이트만 할당해 놓지는 않습니다.

실제로
6 int a = 5;
7 char s[6] = "hello";
8 int t = 10;
9
10 printf("%d %s %dn", a, s, t);
11 strcpy(s, "Good bye Ha Ha Ha!");
12 printf("%d %s %dn", a, s, t);
13 return 1;

이렇게 돌려 보았더니 g++ 3.3.5 버젼에서는 무리 없이 동작했습니다.

5 hello 10
5 Good bye Ha Ha Ha! 10

그 까닭은 char s[6]이 28 byte를 할당을 하더군요. 따라서 "Good bye" 같은 8자 정도는 넣어도 아무런 문제가 발생하지 않습니다.
하지만 모든 컴파일러가 이렇게 해준다는 보장도 없고, 몇 바이트를 할당해준다는 규칙도 없기 때문에 정확히 할당해 놓은 만큼만 사용하는 것이 좋습니다.

VC는 원래 배열이라는 공간이 없습니다.
정확히 말하자면 배열은 포인터와 밀접한 관계가 있죠. 즉 내가 char [6]을 선언한다고 하더라도 정확히 6개의 배열을 할당할 메모리 공간만 잡아주고
배열의 범위를 넘어서 변수를 대입시켜도 그에 대한 에러처리를 해주지 않습니다. 이것이 오히려 VC의 강점이 되기도 하구요..

단, 대입은 시킬수 있을지언정 이것은 메모리에서 확보된 공간이 아닙니다. 언제든지 다른 메모리 값 대입에 의해 손실될수 있거나 이것때문에 문제가 발생할 요지가 큽니다.
실제로 malloc를 통해 대입받은 변수에 공간을 넘어 다른 값을 대입시킨후 메모리를 free시키면 메모리 엑세스 위반 에러가 납니다.

C는 그런부분에 대한 특별한 검사를 하지 않으니 주의하시기 바랍니다.
프린트에서 무리없이 뜬것은 다른 변수값이 엑세스를 하지 않았을 뿐이죠.

-_- 아닙니다. malloc 는 heap에다가 할당하기 때문에 그런 것이고, char s[6] 같은 경우에는 직접 스택에 메모리를 확보합니다.
하지만 제가 위에서 쓴 것과 같이 VC 에서도 char s[6] 이라고 한다고 그래도 정확히 6 바이트만 할당받지 않습니다. 디스어셈블 해본 결과 16바이트를 할당했습니다. (아래로 8바이트를 더 할당하더군요. 따라서 총 24바이트를 할당 받습니다.) 따라서 "good Bye!" 9바이트를 쓴다고 하더라도 16바이트 이내에서 쓴 것이기 때문에 문제 없이 실행되기는 합니다. 하지만 런타임으로 메모리 액세스 체크를 해서 침범했다는 것을 알려주더군요. 이와는 다르게 gcc 같은 경우에는 이런 런타임 체크를 하지 않습니다.
(16바이트 이상을 쓴다면, 스택의 다른 영역을 건드리게 되어서 변수 값이 바뀐다던지, 세그 폴트 등이 발생할 가능성이 있습니다.)

다시 한번 말씀드리지만 아무 이상 없이 실행되었던 것은 컴파일러가 넉넉하게 메모리를 할당했기 때문입니다. 컴파일러가 할당한 영역 이상으로 데이터를 집어 넣으면 당연히 에러납니다.

VC에서 배열이라는 공간이 없다는 얘기는 처음 들어봅니다. 배열과 포인터가 동작이 비슷하기는 하지만, 함수 내에서 배열로 정의한 변수는 반드시 스택 내에 할당되어져 있습니다. 좀 더 자세히 설명해 주실 수 있으신지요?

음.. 참고로 제가 VC에서 테스트 해 본 구문은
int a = 50;
char s[6] = "Hello";
int t = 60;

printf("%d %s %dn", a, s, t);
strcpy(s, "Good Bye!");
printf("%d %s %dn", a, s, t);
이런 구문 이었고 얘를 디스어셈블 해보면
int a = 50;
0041333E mov dword ptr [a],32h
char s[6] = "Hello";
00413345 mov eax,dword ptr [string "Hello" (4261E4h)]
0041334A mov dword ptr [s],eax
0041334D mov cx,word ptr ds:[4261E8h]
00413354 mov word ptr [ebp-14h],cx
int t = 60;
00413358 mov dword ptr [t],3Ch

printf("%d %s %dn", a, s, t);
0041335F mov eax,dword ptr [t]
00413362 push eax
00413363 lea ecx,[s]
00413366 push ecx
00413367 mov edx,dword ptr [a]
0041336A push edx
0041336B push offset string "%d %s %dn" (426358h)
00413370 call @ILT+1245(_printf) (4114E2h)
00413375 add esp,10h
strcpy(s, "Good Bye!");
00413378 push offset string "Good Bye!" (42634Ch)
0041337D lea eax,[s]
00413380 push eax
00413381 call @ILT+575(_strcpy) (411244h)
00413386 add esp,8
printf("%d %s %dn", a, s, t);
00413389 mov eax,dword ptr [t]
0041338C push eax
0041338D lea ecx,[s]
00413390 push ecx
00413391 mov edx,dword ptr [a]
00413394 push edx
00413395 push offset string "%d %s %dn" (426358h)
0041339A call @ILT+1245(_printf) (4114E2h)
0041339F add esp,10h
이렇게 됩니다.

gas 도 어셈 명령어만 다를 뿐 동작은 비슷하게 합니다.

그리고 C 가 java와 달리 런타임으로 array bound check 를 하지 않기 때문에 속도는 빠르지만, 언제나 죽을 수도 있다는 폭탄을 안고 실행을 하고 있다는 뜻도 됩니다. 언제나 해킹의 위험도 도사리고 있고요
장단이 있다고 할 수 있죠. VC의 강점이라기 보다는 C의 특징이라고 하는 게 더 맞을 것 같습니다.

char str[6];
strcpy(str, "Hello My Friend 12345678901234567891234567891231456789123456789123456789");

이것을 디버그 모드로 실행하여서 메모리에 할당된 영역을 보면 메모리에 모든 값이 들어가 있습니다. 그리고 프로그램이 종료하고 사용된 메모리를 해제할때 런타임 에러가 발생됩니다.
위에 말을 듣고 16바이트 이내로 실행했습니다만, 역시 해제 할때 런타임이 발생됩니다.

int iNum[3];
int i;

for(i=0; i<100; ++i)
iNum[i] = i;
이 경우에도 디버그로 실험했을때는 i가 77이 될때까지 무리없이 메모리에 값이 들어가고 있었습니다.
VC는 이러한 배열의 비정상적인 접근에 체크를 해주지 않습니다. 특히나 배열같은 경우는 iNum[10]이라고 선언하면 메모리와 그 접근 형만 int * 10 (40바이트)만 잡아놓습니다.
그리고 이러한 접근에는 포인터가 사용됩니다.

어셈 구문은 보셨는지 모르겠네요. 16바이트 이내에서 해제할 때 런타임이 발생하는 것은 VC 의 통합환경에서 체크를 하기 때문이고, 이는 C와는 아무 관련이 없는 visual studio 의 기능 중 하나입니다. 이 때 생성된 스택 프레임을 보시면 깨져 있지 않은 것을 알 수 있습니다. (깨져야 정상이지만 컴파일러의 배려로 인해 -_- ) 하지만 Hello My Friend ...... 이런 긴 문장을 넣으면 스택 프레임이 당연히 깨지게 됩니다. -_-;
int a = 10;
char str[6];
int b = 20;
printf("%d %s %dn", a, str, b);
strcpy(str, "Hello My Friend 12345678901234567891234567891231456789123456789123456789");
printf("%d %s %dn", a, str, b);
이런 구문이 있는데요 b = 20 까지 실행하고 난 다음의 VC 에서 스택 프레임은
0x0013FEB8 14 00 00 00 ....
0x0013FEBC cc cc cc cc ÌÌÌÌ
0x0013FEC0 cc cc cc cc ÌÌÌÌ
0x0013FEC4 cc cc cc cc ÌÌÌÌ
0x0013FEC8 cc cc cc cc ÌÌÌÌ
0x0013FECC cc cc cc cc ÌÌÌÌ
0x0013FED0 cc cc cc cc ÌÌÌÌ
0x0013FED4 0a 00 00 00 ....
이렇습니다. cc 로 표현된 부분이 char str[6] 을 위해 할당 받아진 공간이라는 걸 알 수 있죠. 당연히 6 바이트 보다 큽니다. -_- 하지만 strcpy 까지 실행하게 되면 스택 프레임이고 뭐고 -_- 남의 스택 프레임까지 침범하게 됩니다.
0x0013FEB8 14 00 00 00 ....
0x0013FEBC cc cc cc cc ÌÌÌÌ
0x0013FEC0 cc cc cc cc ÌÌÌÌ
0x0013FEC4 48 65 6c 6c Hell
0x0013FEC8 6f 20 4d 79 o My
0x0013FECC 20 46 72 69 Fri
0x0013FED0 65 6e 64 20 end
0x0013FED4 31 32 33 34 1234
0x0013FED8 35 36 37 38 5678
0x0013FEDC 39 30 31 32 9012
0x0013FEE0 33 34 35 36 3456
0x0013FEE4 37 38 39 31 7891
0x0013FEE8 32 33 34 35 2345
0x0013FEEC 36 37 38 39 6789
0x0013FEF0 31 32 33 31 1231
0x0013FEF4 34 35 36 37 4567
0x0013FEF8 38 39 31 32 8912
0x0013FEFC 33 34 35 36 3456
0x0013FF00 37 38 39 31 7891
0x0013FF04 32 33 34 35 2345
0x0013FF08 36 37 38 39 6789
0x0013FF0C 00 61 63 6b .ack
-_- str이 할당 받은 공간은 0x0013FED4 까지 인데, 그걸 무시하고 더 덮어썼으니 그 이후에는 어떻게 실행될지 아무도 모릅니다. (죽겠죠 -_-) 보시면 이전 스택 프레임의 ebp 를 저장해 놓은 공간까지 덮어 씌웠으므로 스택 프레임은 복구도 할 수 없습니다. -_-; 이런 경우에는 동작이 정의되어 있지 않습니다.

정리하자면 'VC 에서는 정해진 메모리 이상을 쓸 경우에는 런타임 체크 에러를 내준다. 하지만 이는 C의 특징이 아닌 VC의 기능 중 하나이다. 컴파일러는 스택 오버플로우 어택을 어느 정도 방지 하기 위해 기본 크기 보다 더 큰 공간을 할당해 준다. 따라서 이 이하 (여기에서는 16바이트)로 쓸 경우 스택 오버 플로우는 일어나지 않는다. 하지만 이 이상으로 쓸 경우에는 동작을 보장할 수 없다.' 가 됩니다.

int iNum[3];
int i;

for(i=0; i<100; ++i)
iNum[i] = i;
의 경우도 마찬가지 입니다. int num[3] 이라고 했더니 int 5개의 공간을 할당하더군요. 따라서 5개까지 들어갔을 때까지만 스택이 제대로 살아 있는 것입니다. 77까지 실행이 되었던 것은 for 문을 돌면서 스택 프레임의 다른 값을 참조할 일이 없이 쓰기만 했기 때문에 가능한 일입니다.

그리고 어셈 단위에서는 배열이나 포인터나 그게 그겁니다. 다른 점이 있다면 함수 내에서 선언된 배열은 스택 프레임내의 주소를 갖고 있고, malloc 으로 선언된 포인터는 힙에 실제 영역을 할당 받아 놓고
스택 프레임에는 4바이트 (32비트 운영체제)의 힙 주소를 저장한다는 점만 다르죠. [] 연산으로 접근 할 때 + i * sizeof(data type); read memory 연산을 하는 것은 동일합니다.

이러한 접근에 포인터가 사용된다고 하셨는데, 포인터 형태로 접근을 안하는 배열은 무엇이 있나 궁금하군요.

할당하다와 데이터를 쓴다는건 다른겁니다.

말그대로 할당만 했다면 5가 넘어가는 순간부터 메모리에 접근을 못하게 했겠죠.

즉 겉으로만 할당을 하고 그에 대한 따른 경계선 구분을 하지 않는 것입니다.

그리고 포인터는 다른 언어에서는 주로 사용하는 문법이 아닙니다. C는 배열의 접근을 포인터로 하기 때문에 특별한 경계선 체크를 하지 않는 것이구요. 포인터형태로 접근하기 때문에 배열이라는 의미는 없는 것이지요.

그래서 이런형식의 접근도 가능합니다.

int iNum[10];
int i;

for(i=0; i<20; ++i) {
*((short *)iNum+i) = (short)i;
}

iNum(결과적으로 배열이지만 이것은 실제로는 배열을 가르키는 포인터입니다. 이 실제 값이 있는 곳을 찾아보려고 했지만 찾을만한 방법은 없더군요.)의 캐스팅을 강제로 short * 형으로 바꾸고 2바이트씩 주소를 접근했습니다.

그리고 오버적으로 스택을 할당했다는 부분에 대해서는 컴파일이 디버그 모드여서 그렇게 잡지 않았나 추측을 해봅니다. 실제로 오버적으로 내가 지정하는 것보다 더 할당을 한다는 것 자체가 말이 되는 현상이라고 생각하지 않습니다. 특히나 메모리가 부족한 시스템에서 잘못쓸 경우를 고려해서 오버적으로 스택을 할당해버리면 난감하죠.

위의 결과를 프린트로 찍어봤을때 결과는 이렇게 나왔습니다.
65536
196610
327684
458758
589832
720906
851980
983054
1114128
1245202
즉 배열이라는 것은 C에서 경계선 체크를 하지 않는 넓은 빈 공간 같은 것입니다. 이것을 어떠한 포인터로 캐스팅 하느냐에 따라서 한번에 접근하는 바이트 수는 달라집니다. 즉 int [10]의 배열을 잡고 이것을 char [40] 처럼 쓰는 것도 가능합니다.

-_- 우리는 스택에 배열의 공간을 잡는 것도 '할당'한다고 하고, 힙 내부에 공간을 잡는 것도 '할당'한다고 합니다. 스택에 할당하는 것은 esp 의 값을 컴파일 타임에 미리 계산해서 단지 메모리 내의 공간을 확보하고 있을 뿐이고, 힙 내부에 공간을 잡을 때에는 런타임에 특정한 규칙에 따라 공간을 확보해주고, 확보한 주소를 스택에 저장하며, 남은 공간들의 리스트를 확보하고 있다는 것만 다릅니다.

그리고 gcc, g++, vs 모두 지정한 공간보다 4, 5 개 공간을 더 할당했습니다. 디버그 모드여서 그런 것은 아닙니다. 어셈 분석해보시고, 스택 프레임 메모리 영역 찍어보시면 다 나옵니다. 메모리가 부족한 시스템에서는 컴파일러가 여분의 공간을 확보하지는 않겠죠. (arm cc 와 같은 임베디드 시스템 컴파일러에서도 더 확보합니다. -_-) 여기에서 논의하고 있는 대상이 아니라고 생각됩니다. int로 접근하든 short 으로 접근하든 내가 할당 받은 곳 내부에서만 작업을 하면 아무런 불평을 하지 않습니다. 문제는 더 썼을 경우죠. 10개를 확보하고 20개를 썼을 경우에도 이미 스택 프레임은 깨졌을 것이라고 생각되나, 현재 스택 프레임을 거슬러 올라가는 어떤 작업을 하지 않았기 때문에 에러가 나지 않는 것입니다.

근무시간인데 뭐하고 있나 모르겠네요 . -_- 사장님도 한번 왔다 가셨는데 -_-; 얼른 하던 엔진분석이나 마저 해야겠습니다. -0- 자세한건 시스템 프로그래밍 책에서 스택 프레임과 힙 메모리 할당 부분을 찾아보시는게 -_-;

char a[6]; 이게 스택에 몇바이트를 잡는지를 거꾸로 알아내서 안전하다고 말하는 건 어불성설입니다. 당연히 컴파일러마다 다른 부분이고요.
정확히 말해서, 원 질문과 같은 코드의 동작은 'undefined'. 그러니까 동작해도 정상이고 동작하지 않아도 정상이고 저 프로그램땜에 하드가 날아가도 정상입니다. (물론 저 코드땜에 하드가 날아가는 컴파일러는 아무도 안쓰겠죠? :D )
C컴파일러는 배열을 잡으면 그 배열이 들어갈 수 있는 충분한 공간 - 이 경우엔 6바이트 이상 - 을 컴파일 타임에 확보하고 배열 변수는 컴파일 타임에 그 공간의 시작주소로 해석하며 배열 크기의 경계는 따로 검사하지 않습니다. 즉 위 코드는 컴파일 타임에는 절대 오류를 내지 않으며, 런타임에 예상할 수 없는 동작을 하는 코드라는 것입니다. 예상할 수 없는 동작을 하는 프로그램이 제대로 된 프로그램일 리는 없겠죠? 당장은 작동해도 잠재적인 오류를 갖고 있는 코드입니다.

다시 요약하자면, C표준은 저런 경우에 컴파일러가 오류를 내야 한다고 강제하지 않습니다.

답변 감사합니다;; 왠지 저때문에 음..님과 땟상이 상당히 고생하신듯 하네요ㄱ-;;

아직 배운지 1달도안되서 모르는말이 많지만 그럭저럭 이해는갔습니다. 답변해주신분들 감사해요~'ㅅ'