애플의 MPW C 컴파일러(2006)가 생성한 일부 오류 메시지들

 (cs.cmu.edu)
2P by GN⁺ | ★ favorite | 댓글 1개
  • 애플의 MPW C 컴파일러 오류 메시지를 모은 페이지로, 컴파일러의 String 리소스를 디컴파일해 얻은 실제 발췌라고 함
  • 일반적인 컴파일러 진단 대신 농담과 풍자가 섞인 문장으로 ANSI C 규격, 타입 제약, 문법 오류를 전달함
  • 예시에는 문자열 리터럴 길이, switch 내부 label, typedef 위치, volatile/register 조합, 상수 수정 같은 C 언어 오류가 포함됨
  • void * 조작, void 캐스팅, struct 재정의, goto와 자동 변수 초기화가 얽힌 오류처럼 특정 컴파일 상황을 직접 겨냥함
  • 컴파일러 크기는 324KB이며, 공개 목록은 전체가 아닌 발췌일 가능성이 있고 저작권 문제도 확실하지 않다고 덧붙임

MPW C 컴파일러 오류 메시지 모음

  • 애플의 MPW C 컴파일러가 생성한 오류 메시지 일부를 나열한 페이지임
  • 메시지들은 실제 출력으로 소개되며, 컴파일러의 String 리소스를 디컴파일해 얻은 것이라고 되어 있음
  • 컴파일러 크기가 324KB라서 목록은 전체가 아니라 일부 발췌일 가능성이 있음
  • 저작권 문제에 대해서는 확실하지 않다고 밝힘

농담처럼 보이는 실제 진단 예시

  • C 문법과 ANSI 규격을 비트는 메시지

    • 문자열 리터럴 길이 제한:
      • "String literal too long (I let you have 512 characters, that's 3 more than ANSI said I should)"
    • switch 문 안에는 case나 default label만 있어야 한다는 오류:
      • "...And the lord said, 'lo, there shall only be case or default labels inside a switch statement'"
    • 예상치 못한 typedef 이름을 만난 상황:
      • "a typedef name was a complete surprise to me at this point in your program"
    • ANSI C 조항을 들며 cast 대상이 scalar여야 한다고 지적하는 메시지:
      • "type in (cast) must be scalar; ANSI 3.3.4; page 39, lines 10-11 (I know you don't care, I'm just trying to annoy you)"

  • 타입과 선언 관련 오류

    • volatile과 register를 함께 쓸 수 없다는 메시지:
      • "'Volatile' and 'Register' are not miscible"
    • 상수는 수정할 수 없다는 오류를 풍자적으로 표현함:
      • "You can't modify a constant, float upstream, win an argument with the IRS, or satisfy this compiler"
    • 이미 정의된 struct를 다시 정의하려는 상황:
      • "This struct already has a perfectly good definition"
    • void 관련 cast 제한:
      • "Can't cast a void type to type void (because the ANSI spec. says so, that's why)"
    • void *를 함부로 다룰 수 없다는 메시지:
      • "can't go mucking with a 'void *'"

  • 짧거나 과장된 오류 표현

    • 짧고 직접적인 오류:
      • "Huh ?"
    • 이미 처리한 함수를 다시 만난 상황:
      • "we already did this function"
    • block 밖의 goto, initializer가 있는 자동 변수, 너무 좁은 창을 한꺼번에 다루는 긴 오류:
      • "This label is the target of a goto from outside of the block containing this label AND this block has an automatic variable with an initializer AND your window wasn't wide enough to read this whole error message"
    • 주석 안에서 /*를 발견한 상황:
      • "Call me paranoid but finding '/*' inside this comment makes me suspicious"
    • 한 줄에 오류가 너무 많은 상황:
      • "Too many errors on one line (make fewer)"
    • 심볼 테이블이 가득 찬 fatal heap error:
      • "Symbol table full - fatal heap error; please go buy a RAM upgrade from your local Apple dealer"

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 컴퓨팅에 이런 장난기가 있던 시절이 그립다
    Amazon에 있을 때 매니저가 예전에 404 페이지를 갱신하면서 딸이 그린 고양이 그림을 스캔해 페이지 본문으로 넣었다고 했다. 2009년에 입사했을 때도 그 이미지가 남아 있었지만, 어느 순간 누군가 알아채고 강아지 스톡 사진으로 바꾼 듯했다. 그래도 애셋 이름은 여전히 kayli-kitty.jpg였고, 이후에는 다시 회전하는 사진들로 바뀌면서 원본 흔적은 사라졌다

  • “Symbol table full - fatal heap error; please go buy a RAM upgrade from your local Apple dealer”라니, 컴퓨터를 산 뒤에도 RAM 업그레이드를 살 수 있던 옛 시절이 떠오른다
    지금이라면 “Symbol table full - fatal heap error; please go buy a new Mac with more RAM”이겠지

    • 꼭 그렇지는 않다. Classic Mac OS는 가상 메모리를 지원하지 않아서, 프로그램이 안 쓰는 데이터를 직접 디스크로 내리지 않는 한 모든 게 RAM에 들어가야 했다
      현대 운영체제는 모두 스와핑을 지원하므로 컴파일은 계속되지만 훨씬 느려질 뿐이다. 현대 컴퓨터에서 진짜로 “메모리 부족”이 되려면 RAM과 디스크를 둘 다 채워야 한다
    • SoC의 통합 메모리에 대한 논리는 이해하지만 그래도 아쉽다. 새 Mac Pro조차 RAM 슬롯이 없다
    • 업그레이드 가능한 RAM을 원하면 언제든 PC를 쓰면 된다
    • 요즘은 오히려 더 그렇다. Apple Silicon Mac은 같은 메모리 용량에 두 배의 정보를 저장할 수 있으니, 보잘것없는 8GB 구성에도 FizzBuzz 보일러플레이트 16GB, Google Chrome 탭 4개, 또는 평균 node_modules의 20%를 담을 수 있다

  • “a typedef name was a complete surprise to me at this point in your program”
    재미있는 컴파일러 오류 메시지가 있던 시절이 좋았다. 예전에 한 벤더 컴파일러에서 이런 메시지를 본 적이 있다: “No! But they'll only let me warn you. Danger Will Robinson! Danger!”
    또 “Really! If you are fussing around with void *, just go home or at least back to your editor!”도 있었다. IT 매니저가 그 메시지 때문에 그 벤더를 계속 썼던 것 같다. SDK는 그냥 그랬지만 재미는 있었다

    • C 프로그래밍을 많이 해보진 않았는데, void*가 왜 그렇게 큰 문제였는지 맥락이 궁금하다

  • 가능해진 때부터 원래 MacOS에서 프로그래밍했다. 이런 오류 메시지들을 많이 기억한다. 특히 “Too many errors on one line (make fewer)”가 기억난다
    헤더 파일 하나 바뀌면 빌드가 45분 걸리던 것도 떠오른다

    • 그 시절에는 68k, C, Pascal을 섞어 시스템 확장, 플러그인, XCMD만 만들었다. 프로젝트가 다 작아서 컴파일 시간은 문제가 아니었고 MPW는 천국 같았다
      가장 큰 XCMD는 세 언어가 모두 들어갔는데 MPW가 아무렇지 않게 링크해 줬고, 한 파일 안에 붙여 넣을 작은 코드 블록들이 있는 프로젝트도 자동화하기 쉬웠다. 드문 오류 메시지가 뜰 때마다 크게 웃었던 기억이 난다. 만든 사람, 잘했다

  • 이 컴파일러를 몇 년 동안 쓰다 보니, 너무 큰 함수만 아니면 생성된 68k 객체 코드를 머릿속에서 즉석으로 C 코드로 “역컴파일”할 수 있게 됐다
    MacNosy를 쓰면 보통 몇 시간 안에 앱의 C 소스를 다시 만들 수 있었다. 앱의 MacNosy 파일을 어셈블러 파일과 rsrc 파일로 바꾸는 스크립트가 있었고, 원본과 동등하게 빌드 가능한 앱을 유지한 채 함수를 하나씩 C로 옮길 수 있었다. 처음엔 게임 해킹용으로 썼지만 가끔 버그 수정에도 썼다
    MPW C 컴파일러의 코드 생성이 그렇게 예측 가능했던 건 부분적으로 68k 명령어 집합의 대칭성 덕분이었다. 단순한 컴파일러를 만들었고 그게 잘 동작했다. 대부분의 노력은 다른 곳에 들어갔다. 어떤 코드가 나올지 꽤 정확히 예측할 수 있었기 때문에, 코드 생성이 마음에 안 들면 소스를 고치면 됐다. javac 컴파일러도 비슷한 철학을 가진 점이 좋다. 패턴을 알고 나면 거의 최적에 가까운 바이트코드를 만들 수 있다

  • 90년대 초 교육 회사에서 쓰던 Glockenspiel C++ 컴파일러는 cfront에서 파생된 물건이었는데, 내가 가장 좋아하던 문법 오류 메시지는 그냥 “core dumped”였다
    C++ 자체로도 힘들어하던 수강생들에게, 돈을 받고 가르치는 과정에서 이걸 설명하기가 꽤 난감했다

    • 사용자는 그냥 디버거를 돌려 코어 파일에서 백트레이스를 보면 된다. 그러다 경험이 쌓이면 서로 다른 16진수 주소를 서로 다른 오류 종류와 연결해 배우게 될 테니, 해 될 건 없다

  • “Call me paranoid but finding '/*' inside this comment makes me suspicious”라니, 그건 선생님이 신경 쓸 일이 아니다

    • 컴파일러가 중첩 블록 주석을 지원했으면 좋겠다고 가끔 생각한다. /* 안에 또 /*가 있으면 끝내려면 */가 두 번 필요하게 하는 식이다
      실제로는 끔찍한 아이디어일지도 모르지만, 그랬다면 시간을 아꼈을 상황이 꽤 많았다

  • 페이지 내용과는 살짝 다른 이야기지만, 많은 MPW 유틸리티가 오류 메시지를 포함한 출력을 명령 형태로 생성하던 방식이 정말 좋았다
    터미널이 편집기 버퍼였기 때문에, 해당 줄로 커서를 올리거나 클릭한 뒤 cmd-enter 같은 걸 누르면 관련 파일을 여는 식으로 쓸 수 있었다

    • 선택한 텍스트를 실행하는 건 그냥 Enter 키였던 것 같다
    • Plan 9 같아 보인다

  • “a typedef name was a complete surprise to me at this point in your program”
    이 목록을 수도 없이 봤는데도, 이 메시지는 볼 때마다 크게 웃게 된다

    • gcc의 “Redefinition of ...”나 “Static declaration follows non-static”보다 훨씬 낫다

  • 이전 논의: https://news.ycombinator.com/item?id=30238928
    맥락을 덧붙이면, 저 메시지를 만든 MPW C 컴파일러는 사실 Apple 내부 개발이 아니라 Green Hills Software[1]가 계약으로 만든 것이다. Wikipedia 페이지[2]와 그 출처[3]에도 나오는데, 재미있게도 그 출처 자체가 바로 이 주제다
    [1] https://en.m.wikipedia.org/wiki/Green_Hills_Software
    [2] https://en.m.wikipedia.org/wiki/Macintosh_Programmer%27s_Wor...
    [3] https://web.archive.org/web/20140528005901/http://lists.appl...

답변달기