C 프로그래밍

ex1.c부터 ex22_main.c까지가 책의 예제 번호를 그대로 쓴다. 내용도 그대로다 — ex7.c는 저자 이름 자리에 "Zed" "Shaw"를 넣어 출력하고, ex12.c는 "Zed A. Shaw"를 문자열로 들고 있으며, ex22_main.c:3은 const char *MY_NAME = "Zed A. Shaw";다. ex17.c:117에는 책이 독자에게 남긴 지시문까지 그대로 따라와 있다.

list.c, list_algo.c, darray.c, hashmap.c, dbg.h, minunit.h도 전부 같은 출처다. 헤더 가드가 lcthw_List_h, _lcthw_Hashmap_h, lcthw_List_algos_h로 되어 있다 — 책의 liblcthw 소스 트리에서 그대로 가져온 흔적이다. 함수 사이 공백이 printf( "..." ) ;, who-> name처럼 뭉개져 있는 것은 책 PDF에서 붙여넣었을 때 생기는 전형적인 패턴이다.

결정적 증거는 hashmap_algos.c다. 같은 디렉터리에 hashmap_algos.h가 있는데도 include 경로가 책 저장소 기준 그대로 남아 있어, 커밋된 상태로는 컴파일 자체가 불가능하다.

공정하게 짚으면, 저자가 남의 저작권 표기를 삭제한 정황은 없다. bstrlib.c와 bstrlib.h는 Paul Hsieh의 BSD/GPL 헤더를 온전히 달고 있다. 나머지 파일들(list.c, darray.c, dbg.h 등)은 원본에도 헤더 주석이 없는 파일들이다. 즉 이것은 표기를 뜯어낸 표절이 아니라, 새로 붙였어야 할 표기를 붙이지 않은 것이다.

그래도 지적은 유효하다. 날짜 디렉터리가 과제 제출물이 아닌 개인 학습 기록이라는 점을 감안해 "치명적"이 아닌 "레포 위생"으로 다루더라도, 59바이트짜리 README에 "이 디렉터리는 LCTHW 따라 치기"라는 한 줄이 없다는 것은 10년 뒤 이 레포를 보는 사람이 저자가 쓴 코드와 책 코드를 구분할 수 없게 만든다. 실제로 채점자인 나는 이 구분을 하기 위해 파일별로 헤더 가드와 문자열 리터럴을 대조해야 했다.

musicListSave는 <name>만 제대로 닫고, <album>·<artist>·<genre> 세 줄은 복사·붙여넣기 상태 그대로 </name>으로 닫는다. 파일 첫 줄에는 <?xml version="1.0" encoding="UTF-8"?>를 당당히 박아 놓는다.

이 버그가 살아남은 이유가 더 나쁘다. 같은 커밋에서 작성된 리더(main.cpp:239)는 여는 태그의 접두사만 보고, 값은 "첫 >와 마지막 < 사이"로 잘라낸다. 닫는 태그 이름을 아예 검사하지 않는다. 그래서 앱은 자기가 뱉은 깨진 파일을 멀쩡히 다시 읽고, 저자에게는 아무 증상이 보이지 않는다. 이 포맷은 자기 자신하고만 왕복한다.

genreList는 별도 타입을 만들지 않고 musicInfo의 필드 자리를 바꿔 끼워 재사용한다. 파일에서 읽을 때(:232)는 (name, genre, album, artist) 순으로 섞어 넣고, 삭제할 때(:438, :567)도 같은 순서로 섞어 찾는다. 여기까지는 일관적이다.

그런데 다이얼로그로 곡을 추가하는 두 경로(:459, :549)는 섞지 않은 inputed를 그대로 넣는다. 결과적으로 앱 실행 중에 추가한 곡은 장르 뷰에서 앨범 자리에 원래 앨범이 들어가 그룹 헤더가 어긋나고, 같은 곡을 다시 지우려 하면 섞인 키로 찾기 때문에 genreList에서만 삭제에 실패한다. 파일에서 불러온 곡과 방금 추가한 곡이 서로 다른 규칙으로 저장되는 상태다.

근본 원인은 필드 셔플이라는 발상 자체다. 뷰마다 정렬 키가 다르다면 정렬 비교자를 바꿨어야 했다 — listElements::sort()(musicList.cpp:72–85)에 이미 람다 비교자 두 개가 들어 있으니 세 번째를 추가하면 끝날 일이었다.

table.h:106–109의 본문은 세미콜론도 return도 없고, 멤버 함수 find를 호출하지 않고 이름만 값으로 넘긴다. 템플릿이라 실체화되기 전까지는 파싱만 통과한다. remove(size_t)가 이것을 호출하지만 remove(size_t) 자체를 프로젝트 어디서도 부르지 않는다 — grep으로 확인한 유일한 호출 지점은 table.h:103, 즉 자기 자신뿐이다.

즉 이 프로젝트는 "죽은 코드가 있어서" 빌드되는 것이다. 저자가 언젠가 테이블에서 아이템 하나를 지우려고 손을 대는 순간 빌드가 깨진다. 확인을 위해 object.h만 스텁으로 치환한 뒤 명시적으로 실체화해 보았다.

생성자와 insert가 &(this->raw.back()), 즉 vector<T> 원소의 주소를 unordered_map<size_t, T*>에 저장한다. push_back은 용량 초과 시 버퍼를 재할당하므로, 두 번째 insert부터 이전에 저장한 포인터가 전부 무효가 된다. WM_CREATE에서 topIcon·botIcon에 각각 4개씩 넣으므로 재할당은 실제로 일어난다.

지금 프로그램이 안 죽는 이유는 indexTable을 읽는 코드가 없기 때문이다 — 조회는 전부 raw.at(index)로 한다. 쓰기만 하고 읽지 않는 필드가 UB의 뇌관으로 남아 있는 상태다. 인덱스 → 원소 매핑이 필요했다면 vector의 첨자가 이미 그 매핑이고, 애초에 이 맵이 존재할 이유가 없다.

덧붙여 table<T>의 bool visible;은 생성자(:44–51)에서 초기화되지 않는다. main.cpp는 topBar, botBar, topIcon, botIcon 네 개에만 setVisible을 부르고 topBarText에는 부르지 않는다. FOREACH_TABLE(table.h:11)이 getVisible()로 순회 시작 위치를 정하므로, 매 WM_PAINT마다 초기화되지 않은 bool을 읽는다.

main.cpp:7이 표준 라이브러리 이름 abs를 삼항 연산자 매크로로 덮어쓴다. 전체를 감싸는 괄호가 없다. main.cpp:128에서 abs(X) / 10으로 쓰는 순간 / 10이 삼항의 거짓 가지에만 결합한다.

결과적으로 X > 0일 때는 X 전체가, X ≤ 0일 때는 X/10만 y에 더해진다. 10ms 타이머로 도는 감속 애니메이션이 한쪽 방향에서는 10배 튄다. 같은 매크로를 쓴 :120은 우연히 (abs(...)) / 10처럼 한 겹 더 싸여 있어 정상 동작한다 — 같은 함수 안에서 두 줄이 서로 다르게 동작하는 셈이다.

애니메이션은 전부 SetTimer/WM_TIMER로 돌아가므로 게임 루프가 필요 없다. 그런데 WinMain은 GetMessage 대신 PeekMessage(PM_REMOVE)를 조건 없이 반복한다. 메시지가 없어도 루프가 멈추지 않으므로 유휴 상태에서 코어 하나를 100% 점유한다. 한 글자 수정(while (GetMessage(&messages, NULL, 0, 0)) { ... })으로 해결되는 문제다.

바로 위 :55의 SetProcessWorkingSetSize(hwnd, -1, -1)도 잘못된 호출이다. 이 API의 첫 인자는 프로세스 HANDLE인데 윈도우 HWND를 넘기고 있다. 반환값을 검사하지 않아 실패가 조용히 묻힌다. 워킹셋을 줄이려던 의도로 보이지만 실제로는 아무 일도 일어나지 않는다.

new OpenFileDialog() / new SaveFileDialog()가 네 곳(:476, :493, :572, :618)에 있고 대응하는 delete가 하나도 없다. grep으로 확인한 main.cpp 전체의 delete 개수는 0이다. 더구나 두 클래스의 생성자는 각각 FileName = new TCHAR[MAX_PATH]를 또 할당하므로 다이얼로그 한 번당 두 덩이가 샌다. 이 객체들은 스택에 두면 될 것들이라 new 자체가 불필요했다.

musicListOpen의 malloc(257)도 마찬가지로 해제되지 않는다. 이 함수는 WM_CREATE와 파일 열기 때마다 호출된다. 참고로 sizeof(char) * 257을 할당하고 getline(buffer, 256)으로 읽는데, istream::getline은 두 번째 인자에 널 종료를 포함한 크기를 받으므로 257은 그냥 근거 없는 여유분이다.

</music>을 만나면 무조건 args[0]부터 args[3]까지 접근한다. args의 크기를 한 번도 확인하지 않는다. <music> 블록 안에 필드가 세 개만 있거나, 파일이 중간에 잘렸거나, 사용자가 필드 하나를 지운 XML을 열면 vector::operator[]가 경계 밖을 읽는다 — at()이 아니므로 예외도 던지지 않는다.

같은 클래스의 다른 코드에서는 raw.at(idx)처럼 at()을 쓰고 있어, 저자가 at()의 존재를 모르는 것은 아니다. 외부에서 들어오는 데이터를 다루는 딱 이 지점에서만 검사가 빠졌다.

좌변과 우변을 같은 모양으로 이어 붙이다가 마지막 항만 info.genre 대신 this->genre가 되었다. 양변에 같은 값이 들어가므로 genre는 비교에 아무 영향을 주지 않는다. 이 연산자는 바로 아래 std::less<musicInfo> 특수화(:42–48)가 그대로 위임받아 쓴다.

실제 피해는 제한적이다 — keySearch의 sort/unique(main.cpp:158–159)에서 검색 결과 중복 제거에만 쓰이고, name·album·artist가 전부 같고 genre만 다른 곡은 드물기 때문이다. 그래도 문자열을 연결해서 비교하는 방식 자체가 취약하다. std::tie(name, album, artist, genre) < std::tie(...) 한 줄이면 오타도 나지 않고 (a="x", b="y")와 (a="xy", b="")를 혼동하지도 않는다.

drawing.cpp:94의 preC ^= posC ^= preC ^= posC;는 한 표현식 안에서 preC를 두 번 수정하므로 C++14 이전 기준 미정의 동작이다. 같은 줄을 std::swap(preC, posC)로 쓰면 UB도 없고 의도도 드러난다.

:99–100은 완전히 동일한 drawProc 호출이 두 번 연속이다. 매 행마다 같은 사각형을 두 번 그린다.

draw_loop_text(drawing.cpp:59)와 draw_loop_blt·draw_loop_proc(drawing.h:29, :42)이 table<T>를 값으로 받는다. WM_PAINT마다 vector와 unordered_map이 통째로 복사된다. 게다가 복사본의 indexTable은 원본 vector를 가리키는 포인터를 그대로 들고 온다 — 위에서 지적한 댕글링 문제가 여기서 한 겹 더 꼬인다. const table<T>&로 받았어야 한다. 바로 옆의 draw_loop_list는 실제로 listElements&로 참조를 받고 있어서, 저자가 참조를 모르는 게 아니라 템플릿 쪽에서만 놓친 것으로 보인다.

검색 입력을 WM_KEYDOWN에서 가상 키 코드로 직접 처리하는데, 받아들이는 범위가 'A'–'Z'와 '0'–'9'뿐이다. IME를 거치는 한글은 WM_KEYDOWN으로 오지 않으므로 한 글자도 입력되지 않는다. WM_CHAR(또는 WM_IME_CHAR)를 받았어야 한다. 저장된 list3.xml의 곡 제목이 모두 영문이라 테스트에서도 드러나지 않았을 것이다.

같은 맥락에서 musicList.h:78의 transform(..., toupper)도 위험하다. char를 그대로 toupper에 넘기는데 CP949 한글 바이트는 음수라 UB다. 인덱스 구축 경로(tableInsertString)에도 같은 호출이 있어, 한글 곡명은 검색 인덱스 자체가 어떻게 만들어질지 보장되지 않는다.

musicInputProc은 INPUT_OK를 눌렀을 때만 전역 inputed를 채운다(:93–101). 하지만 X 버튼으로 닫아도 WM_CLOSE → DestroyWindow → WM_DESTROY → PostQuitMessage 경로를 타고 내부 메시지 루프가 빠져나온 뒤, 호출부(:457, :547)는 성공/취소 구분 없이 무조건 musicList.insert(inputed)를 실행한다. inputed는 전역이므로 첫 취소에는 빈 곡이, 이후 취소에는 직전에 입력했던 곡이 다시 들어간다.

다이얼로그 프로시저는 이미 bool musicInput이라는 전역 플래그를 쓰고 있으니, INPUT_OK 분기에서 성공 여부를 따로 세팅하고 호출부에서 검사하면 세 줄로 끝난다.

WM_KEYDOWN 처리의 switch에서 default:가 블록을 열고, 그 안에 case 'O', case 'S', case 'F'가 들어 있다(:472–517). C++ 문법상 유효하고 실제로 동작하지만(Duff's device와 같은 원리), default가 나머지 case보다 위에 있는 형태라 읽는 사람은 이 세 단축키가 죽은 코드라고 오해하기 쉽다. 그냥 default를 맨 아래로 내리면 될 일이다.

같은 함수 :639–641에는 default: break; break;로 도달 불가능한 break가 하나 더 있다.

find_index는 찾으면 인덱스를, 못 찾으면 0을 반환한다(list.c:31). 첫 번째 원소의 인덱스도 0이므로 두 경우를 구별할 수 없다. 호출부는 이 값을 그대로 1 + find_index(...)로 출력한다.

실행으로 재현했다. 리스트에 5만 넣고 77을 검색하면 존재하지 않는 값에 대해 위치를 단언한다.

list_test.c:24는 find의 결과를 검사 없이 insert_next에 넘긴다. find는 못 찾으면 NULL을 반환하고, insert_next는 첫 줄부터 node->next를 역참조한다(list.c:83). 존재하지 않는 위치를 지정해 삽입하면 바로 죽는다.

대화형 입력과 직접 호출 두 경로 모두에서 종료 코드 139(SIGSEGV)를 확인했다. 근본 원인은 scanf의 반환값을 한 번도 확인하지 않는 것과 같은 뿌리다 — list_test.c:19, :31, :40 세 곳 모두 반환값을 버리므로, 숫자가 아닌 입력이 들어오면 arg/input은 :14에서 초기화되지 않은 채 그대로 쓰인다.

create()(list.c:9–15)는 malloc 반환값을 확인하지 않고 바로 result->next에 쓴다. value 필드는 초기화하지 않는다 — 헤드 노드가 쓰레기 값을 들고 다니지만 순회가 head->next부터 시작하도록 일관되게 짜여 있어 증상은 나지 않는다.

remove_node(:64–65)의 if (prev == NULL) return 0;은 도달할 수 없다. find_front_of는 최소한 head를 반환하므로 절대 NULL이 아니다. 주석("prev가 없으면 삭제할 수 없고 0을 반환합니다")까지 붙어 있어 저자가 이 사실을 몰랐음을 보여준다. 반대로 정말 필요한 방어 — node가 이 리스트에 속하지 않을 때 find_front_of의 while이 리스트 끝을 넘어가는 것 — 은 빠져 있다.

프로그램 종료 시 노드를 해제하는 코드가 없다. 다만 이 구조에서 free가 있는 곳(remove_node:73)의 짝은 맞다.

15-11-03/list.cc와 15-11-25/list.cc를 diff로 비교하면 차이가 없다. list.h도 동일하다. 2015-11-03에 커밋된 파일이 2015-11-25 커밋("2015-11-25")에서 한 글자도 수정되지 않은 채 새 디렉터리로 복사됐다. 이 두 커밋이 레포의 마지막 실습 기록이다.

g++ -std=c++11로 빌드하면 첫 오류가 list.h:11에서 나온다. 문제가 한두 개가 아니다 — 아래는 확인한 것 전부다.

• list.h:11–12 — List가 선언되기 전에 ListNode의 생성자 인자로 쓰인다(unknown type name 'List'). 전방 선언한 것은 ListNode 자기 자신이다.
• list.h:11 — 게다가 ListNode(List* next, List* prev)는 타입이 잘못됐다. 멤버 next_/prev_는 ListNode*다.
• list.h:29–30 — List(), ~List() 뒤에 세미콜론이 없다.
• list.h:52 — L->frist() 오타. first다.
• list.cc:56 — ~List::List(). 올바른 문법은 List::~List().
• list.cc:75 — neww ListNode(...) 오타.
• list.cc:64, 76 — this->last_->next = node. next는 멤버 함수이고 필드 이름은 next_이며 private다. 바로 위에 setNext를 정의해 놓고 쓰지 않는다.
• list.cc:24 — delete(this->value_). void*를 delete하는 것은 미정의 동작이다.
• list.cc:84–87 — List_remove가 void*를 선언해 놓고 아무것도 반환하지 않는다.
• 헤더는 List_push(List*, void*)로 선언하고 정의는 List::List_push(void*)다. 선언과 정의가 하나도 맞지 않는다. 애초에 멤버 함수에 List* 인자가 남아 있는 것 자체가 C 코드를 기계적으로 옮기다 만 흔적이다.

정직하게 말하면 이것은 "실패한 연습"이지 "제출한 과제"가 아니다. 하지만 컴파일 한 번만 돌려봤으면 즉시 알 수 있는 상태로 3주를 방치한 뒤 그대로 재커밋했다는 점은 그 자체가 습관의 문제다. 같은 시기 15-11-04와 15-11-09의 list.c도 바이트 단위로 동일하게 중복 커밋되어 있다.