"Hai mai cambiato il valore di 4?" - come è arrivato nel quiz Hayes-Thomas?

Nel 1989 Felix Lee, John Hayes e Angela Thomas scrissero un test di hacker prendendo la forma di un quiz con molte battute da insider, come " Mangi muffe di melma? ”

Sto considerando le seguenti serie:

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

C'è un particolare aneddoto che rende il numero “4” particolare nella serie?

Qualche implementazione di Fortran ha permesso di modificare il valore delle costanti? Questo era possibile in altre lingue di uso comune in quel momento?

Ai vecchi tempi (anni '70 e precedenti) alcuni computer non avevano MMU (e questo è vero oggi per i microcontrollori molto economici).

Su tali sistemi, non esiste una protezione della memoria, quindi nessun segmento di sola lettura nello spazio degli indirizzi e un programma con errori potrebbe sovrascrivere una costante (nella memoria dati o persino all'interno del codice macchina).

I compilatori Fortran a quel tempo passarono argomenti formali per riferimento . Quindi, se lo hai fatto CALL FUN(4)e il SUBROUTINE FUN(I)suo corpo cambia I, ad esempio con un'affermazione I = I + 1nel suo corpo, potresti avere un disastro, cambiando 4 in 5 nel chiamante (o peggio).

^{Ciò valeva anche per i primi microcomputer come l' IBM PC AT originale del 1984, con MS-DOS}

FWIW, sono abbastanza vecchio da aver usato, come un adolescente nei primi anni '70, computer del genere: IBM1620 e CAB500 (in un museo: questi sono computer dell'era degli anni '60!). L'IBM1620 era piuttosto divertente: veniva usato nelle tabelle di memoria per aggiunte e moltiplicazioni (e se sovrascrivevi queste tabelle, ne conseguiva il caos). Quindi non solo potresti sovrascrivere un 4, ma potresti anche sovrascrivere ogni futura aggiunta 2 + 2 o moltiplicazioni 7 * 8 (ma ho davvero dimenticato questi dettagli sporchi, quindi potrebbe essere sbagliato).

Oggi potresti sovrascrivere il codice BIOS nella memoria flash, se sei abbastanza perseverante. Purtroppo, non mi sento più così divertente, quindi non ci ho mai provato. (Ho anche paura di installare alcuni LinuxBios sulla mia scheda madre).

Sui computer e sistemi operativi attuali il passaggio di una costante come riferimento e la modifica all'interno della chiamata provocherà semplicemente una violazione della segmentazione , che risulta familiare a molti sviluppatori C o C ++.

A proposito: essere pignoli: sovrascrivere 4 non è una questione di linguaggio, ma di implementazione.

È stato un effetto collaterale involontario della strategia di valutazione delle chiamate di funzione FORTRAN in combinazione con un'ottimizzazione del compilatore errata.

FORTRAN II ha introdotto funzioni e subroutine definite dall'utente con i loro argomenti passati per riferimento . (Perché, non lo so. Probabilmente era più efficiente del valore pass-by sull'hardware IBM dell'epoca.)

Normalmente, pass-by-reference significa che devi passare un valore l (come una variabile) invece di un valore r. Ma i progettisti di FORTRAN hanno deciso di essere d'aiuto e di lasciarti comunque passare valori-r come argomenti. Il compilatore genererebbe automaticamente una variabile per te. Quindi, se hai scritto:

CALL SUBFOO(X + Y, 4)

il compilatore lo convertirà dietro le quinte in qualcosa del genere

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

C'era anche una comune ottimizzazione del compilatore chiamata "pool letterale", che avrebbe consolidato più istanze della stessa costante numerica nella stessa variabile generata automaticamente. (Diverse lingue della famiglia C richiedono questo per i letterali stringa.) Quindi, se hai scritto

CALL SUBBAR(4)
CALL SUBBAZ(4)

questo sarebbe trattato come se fosse

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

che sembra una cosa perfettamente ragionevole da fare fino a quando non si ha un sottoprogramma che modifica il valore dei suoi parametri.

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

Boom! CALL SUBBAR(4)ha cambiato il valore di 4 nel pool letterale in 5. E poi ti stai chiedendo perché SUBBAZstai assumendo di averlo passato un 5 invece di quello che 4hai effettivamente scritto nel codice.

Le versioni più recenti di Fortran mitigano questo problema consentendo di dichiarare la INTENTvariabile come INo OUTe dandoti un errore (o almeno un avviso) se passi una costante come OUTparametro.

In FORTRAN, quando una costante viene passata a un'altra procedura, non viene più protetta. Questo è ciò a cui si riferiscono. Altri linguaggi di programmazione popolari in quel periodo erano C e Pascal che non avevano (e ancora non hanno) questo problema. Forse ci sono linguaggi di programmazione più vecchi di cui non sono a conoscenza che hanno lo stesso problema.