2022년 글 재조명: C 언어 살리려면 ABI를 부수는 대신 '고쳐서' 살려야 한다는 주장

C는 원래 하드웨어에 가깝다고 알려져 있지만 사실 다른 고수준 언어랑 똑같음. 어셈블리 확장은 각 컴파일러가 따로 넣은 거고 ISO C 표준에는 원래 없었음

정수 타입은 예외긴 함. CHAR_BIT를 12로 만들어서 사람들 괴롭혀도 되고 ㅋㅋ 개인적으론 C가 '어디든 포팅 가능한 컴파일러'에 가깝지 '어디서든 도는 코드'는 아니라고 봄

엄밀히 말하면 표준화된 C ABI라는 건 존재하지 않음. ABI는 CPU랑 OS 벤더가 정하는 거고, C 친화적으로 맞춰지긴 하지만 필수는 아님. 아미가OS ABI가 좋은 예시임

호환성이 산업 전체를 굴리는 거라 이해는 함. PLC나 하드웨어 회사들 보면 '안전인증코드'라고 하지만 사실 그냥 옛날 코드 계속 쓰는 거고, 하드웨어 쪽 프로그래머는 급여도 낮은데 새 걸 배우라고 하면 반발하는 게 당연함

맞음, 게다가 그런 시스템은 수백만 달러짜리 장비를 돌리는 거라 뭐 하나 깨지면 화학 공장이 24시간 멈추는 수준의 재앙이 됨. 그러니 다들 보수적으로 갈 수밖에 없음

이 글 이후로 실제로 바뀐 건 없음

완전히 없는 건 아님, N3913 문서가 계속 업데이트되고 있어서 위원회가 이 접근을 아예 거부한 건 아닌 걸로 보임

이 글 결국 'intmax_t가 ABI 안정적이지 않다'는 얘기 수천 단어로 늘린 거잖음, 다 아는 얘기임

그건 좀 축소한 거임. 글 절반 가까이는 ABI를 진화시키는 메커니즘 얘기고, 저자가 Clang 포크에 구현해서 C 위원회에 N2901/N3913으로 제출까지 했음

더 큰 문제는 time_t라고 봄. 나는 코드에 '2038년 1월19일 이전까지만 유효함'이라고 주석 써놨는데, 재인증 규제 때문에 다시 컴파일도 안 될 거임

COM 같은 C ABI가 C++를 구했다고 봄

타입 라이브러리랑 메타데이터까지 다 무시하면 그렇게 말할 수 있겠지

제목에 (2022) 붙여야 함, 딱히 바뀐 건 없지만 하늘이 무너지지도 않았음. 결국 OS/CPU 조합이 ABI를 정하고 컴파일러는 그냥 거기 맞출 뿐임

OS ABI는 사실 '90년대에 제일 잘 나가던 컴파일러가 했던 방식'을 그대로 정의한 거라 언어랑 독립적이지 않음. 그래서 새 언어는 ABI 접근을 위해 C 컴파일러를 내장해야 함

'우리 선조들이 이런 영구적인 결정을 내릴 만큼 똑똑하지 못했다'는 표현은 불필요한 오만임. 그때 사람들도 충분히 똑똑했고 그냥 다른 제약 조건을 마주했던 거임

그때는 컴퓨터가 훨씬 느리고 메모리도 극히 제한적이어서 지금처럼 비용 거의 안 드는 트릭을 쓸 여유가 없었음

새 시스템 언어들이 다들 자체 ABI를 안정적으로 가지려고 안 해서 결국 경계에서는 다 C인 척해야 하는 게 제일 답답함