ข้อความผิดพลาดบางส่วนที่สร้างโดยคอมไพเลอร์ MPW C ของ Apple (2006)

 (cs.cmu.edu)
2 คะแนน โดย GN⁺ 2023-08-28 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เป็นหน้าที่รวบรวมข้อความผิดพลาดของ คอมไพเลอร์ MPW C ของ Apple โดยระบุว่าเป็นข้อความที่คัดมาจริงจากการ decompile String resource ของคอมไพเลอร์
  • แทนที่จะเป็น diagnostic ของคอมไพเลอร์ทั่วไป ข้อความเหล่านี้สื่อถึงข้อกำหนด ANSI C, ข้อจำกัดด้าน type และ syntax error ด้วยประโยคที่ผสม มุกตลกและการเสียดสี
  • ตัวอย่างรวมถึง ข้อผิดพลาดของภาษา C เช่น ความยาวของ string literal, label ภายใน switch, ตำแหน่งของ typedef, การใช้ volatile ร่วมกับ register, และการแก้ไขค่าคงที่
  • มุ่งเจาะจง สถานการณ์การคอมไพล์ บางแบบโดยตรง เช่น การจัดการ void *, การ cast void, การนิยาม struct ซ้ำ, และข้อผิดพลาดที่เกี่ยวข้องกับ goto กับการ initialize ตัวแปร automatic
  • ขนาดคอมไพเลอร์อยู่ที่ 324KB และเสริมว่ารายการที่เผยแพร่น่าจะเป็นเพียงส่วนที่คัดมา ไม่ใช่ทั้งหมด อีกทั้งประเด็นลิขสิทธิ์ก็ยังไม่แน่ชัด

รวมข้อความผิดพลาดของคอมไพเลอร์ MPW C

  • เป็นหน้าที่ลิสต์ข้อความผิดพลาดบางส่วนที่สร้างโดย คอมไพเลอร์ MPW C ของ Apple
  • ข้อความเหล่านี้ถูกนำเสนอว่าเป็น output จริง และระบุว่าได้มาจากการ decompile String resource ของคอมไพเลอร์
  • เนื่องจากคอมไพเลอร์มีขนาด 324KB รายการนี้จึงอาจเป็นเพียงส่วนที่คัดมา ไม่ใช่ทั้งหมด
  • ระบุว่าไม่แน่ชัดในประเด็นลิขสิทธิ์

ตัวอย่าง diagnostic จริงที่ดูเหมือนมุกตลก

  • ข้อความที่เล่นกับ syntax ของ C และมาตรฐาน ANSI

    • ข้อจำกัดความยาวของ string literal:
      • "String literal too long (I let you have 512 characters, that's 3 more than ANSI said I should)"
    • ข้อผิดพลาดที่ระบุว่าในคำสั่ง switch ต้องมีได้เฉพาะ label แบบ case หรือ default:
      • "...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)"

  • ข้อผิดพลาดเกี่ยวกับ type และ declaration

    • ข้อความที่ระบุว่าไม่สามารถใช้ 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 ที่มี definition ดีอยู่แล้วซ้ำอีก:
      • "This struct already has a perfectly good definition"
    • ข้อจำกัดการ cast ที่เกี่ยวกับ void:
      • "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"
    • ข้อผิดพลาดยาวที่กล่าวถึง goto จากนอก block, ตัวแปร automatic ที่มี 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"
    • สถานการณ์ที่พบ /* ภายใน comment:
      • "Call me paranoid but finding '/*' inside this comment makes me suspicious"
    • สถานการณ์ที่มีข้อผิดพลาดมากเกินไปในหนึ่งบรรทัด:
      • "Too many errors on one line (make fewer)"
    • fatal heap error จาก symbol table เต็ม:
      • "Symbol table full - fatal heap error; please go buy a RAM upgrade from your local Apple dealer"

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-08-28
ความคิดเห็นจาก Hacker News

  • คิดถึงยุคที่วงการคอมพิวเตอร์ยังมี ความขี้เล่น แบบนี้
    ตอนอยู่ Amazon ผู้จัดการเคยเล่าว่า สมัยก่อนตอนอัปเดตหน้า 404 เขาสแกนรูปแมวที่ลูกสาววาดแล้วใส่ไว้ในเนื้อหาของหน้า ตอนผมเข้าทำงานในปี 2009 รูปนั้นก็ยังอยู่ แต่ถึงจุดหนึ่งคงมีใครสังเกตเห็นแล้วเปลี่ยนเป็นรูปสต็อกของสุนัขแทน ถึงอย่างนั้นชื่อ asset ก็ยังเป็น kayli-kitty.jpg อยู่ดี และต่อมาก็เปลี่ยนอีกครั้งเป็นชุดรูปที่หมุนสลับกัน ทำให้ร่องรอยต้นฉบับหายไป

    • เจ๋งจริง ๆ หน้า 404 บางหน้าของ Amazon เช่น https://www.amazon.co.jp/404 ชื่อไฟล์ยังเป็น kailey-kitty.gif อยู่ แต่รูปถูกเปลี่ยนเป็นไอคอนมาตรฐานแล้ว
      ยังเจอคอมเมนต์บล็อกที่เกี่ยวข้องด้วย: https://www.davebellous.com/2006/09/25/what-the/#comment-290...
    • “คอมไพเลอร์ขนาด 324k” นี่แปลว่าสิ่งที่เราสูญเสียไปไม่ได้มีแค่ความขี้เล่นแล้วล่ะ ซอฟต์แวร์บวม มาถึงระดับตลกไปแล้ว
    • หาเจ้ารูปแมวที่หายากนั้นใน archive.org ไม่เจอ แต่เจอ รูปสุนัข นี้แทน: https://web.archive.org/web/20030113144310/https://www.amazo...
      ดูเหมือน Amazon จะเริ่มใช้หน้าข้อผิดพลาดแบบปัจจุบันที่มีรูปสุนัขขนาดใหญ่ราวเดือนมิถุนายน 2016: https://web.archive.org/web/20160612232820/http://www.amazon...
    • เปิด www.amazon.com แล้วดู ซอร์ส ทันทีสิ :)
    • หลังลูกสาวอายุ 18 ปี เธออาจฟ้องเรื่อง ละเมิดลิขสิทธิ์ ก็ได้นะ ;)
      ถามจริง ๆ ด้วยความสงสัย แบบนี้เป็นไปได้ไหม แม้ผู้ปกครองจะเคยยินยอมไว้ก่อนแล้ว?

  • “Symbol table full - fatal heap error; please go buy a RAM upgrade from your local Apple dealer” ทำให้นึกถึงยุคเก่า ๆ ที่ซื้อคอมพิวเตอร์แล้วก็ยังซื้อ RAM upgrade เพิ่มได้
    ถ้าเป็นตอนนี้คงเป็น “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 อันน่าสงสาร ก็ยังใส่โค้ด boilerplate FizzBuzz ได้ 16GB, แท็บ Google Chrome 4 แท็บ หรือ 20% ของ node_modules โดยเฉลี่ยได้

  • “a typedef name was a complete surprise to me at this point in your program”
    ชอบยุคที่มี ข้อความข้อผิดพลาดของคอมไพเลอร์ สนุก ๆ แบบนี้ เคยเห็นข้อความนี้ในคอมไพเลอร์ของ vendor รายหนึ่ง: “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 manager คงใช้ vendor นั้นต่อเพราะข้อความพวกนี้แหละ SDK ก็เฉย ๆ แต่สนุกดี

    • ผมไม่ได้เขียน C มากนัก เลยอยากรู้บริบทว่า void* เป็น ปัญหาใหญ่ ขนาดนั้นเพราะอะไร

  • ผมเขียนโปรแกรมบน MacOS ดั้งเดิมมาตั้งแต่เริ่มทำได้ จำข้อความผิดพลาดพวกนี้ได้หลายอัน โดยเฉพาะ “Too many errors on one line (make fewer)”
    ยังนึกถึงเวลาที่เปลี่ยนไฟล์ header ไฟล์เดียวแล้ว build ใช้เวลา 45 นาทีด้วย

    • สมัยนั้นผมทำแค่ system extension, plug-in และ XCMD โดยผสม 68k, C, Pascal เข้าด้วยกัน โปรเจกต์ล้วนเล็ก ๆ เวลา compile เลยไม่ใช่ปัญหา และ MPW ก็เหมือนสวรรค์
      XCMD ที่ใหญ่ที่สุดมีทั้งสามภาษา แต่ MPW ก็ link ให้ได้สบาย ๆ และโปรเจกต์ที่มีบล็อกโค้ดเล็ก ๆ ให้ paste รวมไว้ในไฟล์เดียวก็ทำ automation ได้ง่าย จำได้ว่าหัวเราะดังทุกครั้งที่ข้อความผิดพลาดหายาก ๆ โผล่ขึ้นมา คนทำ เก่งมาก

  • หลังใช้คอมไพเลอร์นี้อยู่หลายปี ผมก็สามารถ “decompile” 68k object code ที่ถูกสร้างขึ้นกลับเป็นโค้ด C ในหัวได้ทันที ตราบใดที่ไม่ใช่ฟังก์ชันที่ใหญ่เกินไป
    ถ้าใช้ MacNosy โดยปกติจะสร้างซอร์ส C ของแอปกลับมาได้ภายในไม่กี่ชั่วโมง ผมมีสคริปต์ที่แปลงไฟล์ MacNosy ของแอปให้เป็นไฟล์ assembler กับไฟล์ rsrc และสามารถค่อย ๆ ย้ายฟังก์ชันทีละตัวไปเป็น C โดยยังรักษาแอปที่ build ได้เทียบเท่าต้นฉบับไว้ ตอนแรกใช้เพื่อแฮ็กเกม แต่บางครั้งก็ใช้แก้บั๊กด้วย
    ส่วนหนึ่งที่การสร้างโค้ดของคอมไพเลอร์ MPW C คาดเดาได้ขนาดนั้น เป็นเพราะความสมมาตรของ ชุดคำสั่ง 68k เขาทำคอมไพเลอร์แบบเรียบง่าย และมันก็ทำงานได้ดี ความพยายามส่วนใหญ่ไปอยู่ที่ส่วนอื่น เพราะผมทำนายได้ค่อนข้างแม่นว่าจะได้โค้ดแบบไหนออกมา ดังนั้นถ้าไม่ชอบ code generation ก็แก้ source เอาได้เลย ผมชอบที่คอมไพเลอร์ javac ก็มีปรัชญาคล้ายกัน พอรู้ pattern แล้วก็สร้าง bytecode ที่เกือบเหมาะที่สุดได้

  • คอมไพเลอร์ Glockenspiel C++ ที่ใช้กันในบริษัทด้านการศึกษาช่วงต้นยุค 90 เป็นสิ่งที่แยกสายมาจาก cfront และ ข้อความแจ้งข้อผิดพลาดทางไวยากรณ์ ที่ผมชอบที่สุดก็คือ “core dumped” เฉย ๆ
    ในคอร์สที่เก็บเงินสอน การต้องอธิบายเรื่องนี้ให้ผู้เรียนที่ลำบากกับตัว C++ อยู่แล้วฟังนั้นค่อนข้างกระอักกระอ่วน

    • ผู้ใช้ก็แค่รันดีบักเกอร์แล้วดู แบ็กเทรซ ในไฟล์ core ก็พอ จากนั้นพอมีประสบการณ์มากขึ้น ก็จะได้เรียนรู้การเชื่อมโยงที่อยู่เลขฐานสิบหกต่าง ๆ เข้ากับชนิดข้อผิดพลาดต่าง ๆ เอง ดังนั้นก็ไม่เสียหายอะไร

  • “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”
    แม้จะเคยเห็นรายการนี้มานับครั้งไม่ถ้วนแล้ว แต่ข้อความนี้ก็ยังทำให้หัวเราะลั่นทุกครั้งที่เห็น

    • ดีกว่า “Redefinition of ...” หรือ “Static declaration follows non-static” ของ gcc เยอะ

  • การสนทนาก่อนหน้านี้: 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...