http://pages.cs.wisc.edu/~cs354-1/onyourown/C.argv.html

여기서 찾았네요(영문 사이트입니다)

원래는 argv의 범주는 0~(argc-1)이지만, ANSI C에서 argv[argc]는 NULL로 초기화 하게 되어있더군요.

그런데 이유가, char **argv 라고 할때, 컴파일러는 그냥 argv를 가져다 써도 이것을 문자열(...)로 인식한다네요.

이건 C언어 자체가 문자와 문자열 포인터를 구분하지 않게 되있어서(........) 생기는 문제로

문자열을 처리하듯이 NULL문자를 찾을때 까지 진행하는데, 이때 프로그램이 죽는것을 방지하기 위해 마지막에 null을 달아준다고 합니다.

결국은 문자 포인터의 배열을 문자열 처럼 처리가능하게 해주기 위해 마지막에 NULL을 달아준 것으로

링크에서 표현했다 시피, argv자체를 문자열처럼 쓰는 잘못된 코드에 대비하기 위해서 달아놓은 것이라고 하네요...

그리고 개인적인 실험 결과로, argv가 어디까지 자동 초기화 되냐는 결과인데

결론적으로 컴파일러(또는 링커) 설정에 따라 다른것 같습니다.

VS2010에선 4813번 인덱스까지 NULL 또는 NULL 문자열을 가리키도록 초기화 되어있고

GCC3.4.2 for Windows 에선 123번 인덱스까지 NULL 또는 NULL문자열을 가리키도록 되어 있네요.

아무래도 컴파일시에 MAX_ARG_SIZE 설정에 따라, 미리 최대 인자 사이즈만큼 argv를 만들어 놓고

거기에 차례대로 집어넣으면서 argc를 카운트하는 것 같습니다.

예전에는 메모리 낭비였겠지만, 요즘 컴퓨터에 VS2010기준 약 1KB내외의 메모리 정도는 낭비했는지도 모를테니

그냥 미리 최대사이즈만큼 크게 만들어 놓고 쓰는 것 같습니다.

실행시 메모리 할당 횟수가 많으면 런타임이 늘어날테니 한번에 잡아놓자는 목적도 있을것 같구요.

아무튼 argv[argc] == NULL 이 된 이유는 게으른 코더의 실수로 프로그램이 뻗는걸 방지하기 위한 ANSI의 친절의 결과 같습니다;
(메모리보호가 없는 환경에서는 시스템 크래시를 막기위해서 필요할지도 모르겠네요)