“ เคยเปลี่ยนค่าของ 4 หรือไม่?” - สิ่งนี้เกิดขึ้นได้อย่างไรในแบบทดสอบ Hayes-Thomas

ในปี 1989 เฟลิกซ์ลีจอห์นเฮย์สและแองเจลาโทมัสเขียนทดสอบแฮกเกอร์รูปแบบของการตอบคำถามที่มีเรื่องตลกภายในหลาย ๆ ขณะที่“ คุณกินเมือกแม่พิมพ์? ”

ฉันกำลังพิจารณาชุดต่อไปนี้:

0015 Ever change the value of 4?
0016 ... Unintentionally?
0017 ... In a language other than Fortran?

มีเกร็ดเล็กเกร็ดน้อยเกี่ยวกับการสร้างหมายเลข“ 4” โดยเฉพาะในซีรี่ส์หรือไม่?

การใช้ Fortran บางอย่างอนุญาตให้แก้ไขค่าของค่าคงที่หรือไม่ เป็นไปได้ในภาษาอื่นที่ใช้งานทั่วไปในเวลานั้นหรือไม่?

ในสมัยก่อน (1970 และก่อนหน้า) คอมพิวเตอร์บางเครื่องไม่มีMMU (และนี่เป็นความจริงในปัจจุบันสำหรับไมโครคอนโทรลเลอร์ที่มีราคาถูกมาก)

ในระบบดังกล่าวไม่มีการป้องกันหน่วยความจำจึงไม่มีเซ็กเมนต์แบบอ่านอย่างเดียวในพื้นที่ที่อยู่และโปรแกรม buggy สามารถเขียนทับค่าคงที่ (ทั้งในหน่วยความจำข้อมูลหรือแม้แต่ในรหัสเครื่อง)

คอมไพเลอร์ Fortran ในเวลานั้นอย่างเป็นทางการผ่านการขัดแย้งโดยการอ้างอิง ดังนั้นถ้าคุณทำCALL FUN(4)และสิ่งSUBROUTINE FUN(I)นั้นเปลี่ยนแปลงร่างกายI- เช่นด้วยคำแถลงI = I + 1ในร่างกายคุณอาจประสบภัยพิบัติเปลี่ยนเป็น 4 ใน 5 ในผู้โทร (หรือแย่กว่านั้น)

^{สิ่งนี้ก็เป็นจริงเช่นกันในไมโครคอมพิวเตอร์ตัวแรกเช่นIBM PC ATดั้งเดิมตั้งแต่ปี 1984 ด้วย MS-DOS}

FWIW ฉันอายุมากพอที่จะใช้เป็นวัยรุ่นวัยต้นปี 1970 คอมพิวเตอร์เช่น IBM1620 และ CAB500 (ในพิพิธภัณฑ์: คอมพิวเตอร์ยุคนี้เป็นยุค 1960!) IBM1620 ค่อนข้างสนุก: มันใช้ในตารางหน่วยความจำสำหรับการเพิ่มและการคูณ (และถ้าคุณเขียนทับตารางเหล่านี้จะเกิดความโกลาหล) ดังนั้นไม่เพียง แต่คุณสามารถเขียนทับ 4 แต่คุณสามารถเขียนทับทุก 2 + 2 นอกจากนี้ในอนาคตหรือการคูณ 7 * 8 (แต่ฉันลืมรายละเอียดที่สกปรกเหล่านี้ดังนั้นอาจผิด)

วันนี้คุณอาจเขียนทับรหัส BIOS ในหน่วยความจำแฟลชถ้าคุณมีความพยายามมากพอ น่าเศร้าที่ฉันไม่รู้สึกสนุกอีกต่อไปดังนั้นฉันจึงไม่เคยลอง (ฉันกลัวที่จะติดตั้ง LinuxBios บางตัวบนเมนบอร์ดของฉัน)

ในคอมพิวเตอร์ปัจจุบันและระบบปฏิบัติการที่ผ่านค่าคงที่โดยการอ้างอิงและการเปลี่ยนแปลงภายใน callee เพียงแค่จะก่อให้เกิดการละเมิดการแบ่งส่วนซึ่งฟังดูคุ้นเคยกับนักพัฒนา C หรือ C ++ หลายคน

BTW: การเป็น nitpicking: การเขียนทับ 4 ไม่ใช่เรื่องของภาษา แต่เป็นการใช้งาน

มันเป็นผลข้างเคียงที่ไม่ได้ตั้งใจของกลยุทธ์การประเมินการเรียกใช้ฟังก์ชันของ FORTRAN ร่วมกับการเพิ่มประสิทธิภาพคอมไพเลอร์ที่ผิดพลาด

FORTRAN II แนะนำฟังก์ชั่นที่ผู้ใช้กำหนดและซับรูทีนที่มีการขัดแย้งของพวกเขาผ่านอ้างอิง (เพราะเหตุใดฉันไม่รู้มันอาจมีประสิทธิภาพมากกว่าฮาร์ดแวร์แบบ pass-by-value ในเวลานั้น)

โดยปกติการอ้างอิงแบบ pass-by-reference หมายความว่าคุณจะต้องผ่านค่า l-value (เช่นตัวแปร) แทนค่า r-value แต่นักออกแบบของ FORTRAN ตัดสินใจที่จะเป็นประโยชน์และให้คุณส่งค่า r-values ​​เป็นอาร์กิวเมนต์ต่อไป คอมไพเลอร์จะสร้างตัวแปรให้คุณโดยอัตโนมัติ ดังนั้นถ้าคุณเขียนว่า:

CALL SUBFOO(X + Y, 4)

คอมไพเลอร์จะแปลงสิ่งนี้เบื้องหลังให้เป็นอย่าง

TEMP1 = X + Y
TEMP2 = 4
CALL SUBFOO(TEMP1, TEMP2)

นอกจากนี้ยังมีการเพิ่มประสิทธิภาพคอมไพเลอร์ทั่วไปที่เรียกว่า“ สระรวม” ซึ่งจะรวมหลายอินสแตนซ์ของค่าคงที่ตัวเลขเดียวกันเป็นตัวแปรที่สร้างขึ้นอัตโนมัติเดียวกัน (หลายภาษาในตระกูล C จำเป็นต้องใช้สิ่งนี้สำหรับตัวอักษรสตริง) ดังนั้นหากคุณเขียน

CALL SUBBAR(4)
CALL SUBBAZ(4)

นี้จะได้รับการปฏิบัติราวกับว่ามันเป็น

FOUR = 4
CALL SUBBAR(FOUR)
CALL SUBBAZ(FOUR)

ซึ่งดูเหมือนจะเป็นสิ่งที่สมเหตุสมผลอย่างสมบูรณ์แบบจนกว่าคุณจะมีโปรแกรมย่อยที่เปลี่ยนค่าของพารามิเตอร์

SUBROUTINE SUBBAR(X)
    !...lots of code...
    X = 5
    !...lots of code...
END SUBROUTINE SUBBAR

บูม! CALL SUBBAR(4)เปลี่ยนค่าของ 4 ในพูลตัวอักษรเป็น 5 จากนั้นคุณเหลือสงสัยว่าทำไมSUBBAZคุณสมมติว่าคุณผ่าน 5 แทนการ4เขียนโค้ดจริง

เวอร์ชั่นใหม่ของ Fortran ช่วยลดปัญหานี้โดยให้คุณประกาศINTENTตัวแปรเป็นINหรือOUTและทำให้คุณมีข้อผิดพลาด (หรืออย่างน้อยคำเตือน) หากคุณผ่านค่าคงที่เป็นOUTพารามิเตอร์

ใน FORTRAN เมื่อค่าคงที่ถูกส่งผ่านไปยังโพรซีเดอร์อื่นจะไม่ได้รับการป้องกันอีกต่อไป นั่นคือสิ่งที่พวกเขาอ้างถึง ภาษาการเขียนโปรแกรมยอดนิยมอื่น ๆ ในเวลาเดียวกันคือ C และ Pascal ซึ่งไม่มี (และยังไม่มี) มีปัญหานี้ อาจมีภาษาโปรแกรมเก่ากว่าซึ่งฉันไม่ทราบว่ามีปัญหาเดียวกัน