Che cos'è un linguaggio di programmazione sicuro?


54

I linguaggi di programmazione sicura (PL) stanno guadagnando popolarità. Mi chiedo quale sia la definizione formale di PL sicuro. Ad esempio, C non è sicuro, ma Java è sicuro. Ho il sospetto che la proprietà "sicura" dovrebbe essere applicata a un'implementazione PL piuttosto che al PL stesso. In tal caso, discutiamo una definizione di implementazione di PL sicura. I miei tentativi di formalizzare questa nozione hanno portato a uno strano risultato, quindi vorrei sentire altre opinioni. Per favore, non dire che ogni PL ha comandi non sicuri. Possiamo sempre prendere un sottoinsieme sicuro.


I commenti non sono per una discussione estesa; questa conversazione è stata spostata in chat .
Gilles 'SO- smetti di essere malvagio' il

"possiamo sempre prendere un sottoinsieme sicuro" Come puoi essere sicuro che la lingua risultante sia ancora Turing completa? (che di solito si intende per "linguaggio di programmazione")
effeffe

"la proprietà" sicura "dovrebbe essere applicata a un'implementazione PL anziché al PL stesso" - puoi chiamare una PL sicura se esiste un'implementazione sicura di essa.
Dmitry Grigoryev,

Risposte:


17

Quando in qualche modo chiamiamo una lingua "sicura" , ciò significa formalmente che c'è una prova che nessun programma ben strutturato nella lingua può fare qualcosa che consideriamo pericoloso. Anche la parola "sicuro" è usata in modo meno formale, ma è quello che le persone qui comprendono la tua domanda. Esistono molte diverse definizioni di proprietà che vogliamo avere un linguaggio “sicuro”.

Alcuni importanti sono:

  • La definizione di "solidità del tipo" di Andrew Wright e Matthias Felleisen , che è citata in molti luoghi (tra cui Wikipedia) come una definizione accettata di "sicurezza del tipo" e la loro prova del 1994 che un sottogruppo di ML la soddisfa.

  • Michael Hicks elenca qui diverse definizioni di "sicurezza della memoria" . Alcuni sono elenchi di tipi di errori che non possono verificarsi e altri si basano sul trattamento dei puntatori come funzionalità. Java garantisce che nessuno di questi errori è possibile (a meno che non si usi esplicitamente una funzione contrassegnata unsafe) facendo in modo che un garbage collector gestisca tutte le allocazioni e le deallocazioni. Rust offre la stessa garanzia (di nuovo, a meno che tu non contrassegni esplicitamente il codice come unsafe), attraverso il suo sistema di tipo affine, che richiede che una variabile sia posseduta o presa in prestito prima di essere utilizzata al massimo una volta.

  • Allo stesso modo, il codice thread-safe è di solito definito come codice che non può mostrare determinati tipi di bug che coinvolgono thread e memoria condivisa, tra cui corse di dati e deadlock. Queste proprietà sono spesso applicate a livello di linguaggio: Rust garantisce che non si possano verificare corse di dati nel suo sistema di tipi, C ++ garantisce che i suoi std::shared_ptrpuntatori intelligenti sugli stessi oggetti in più thread non elimineranno prematuramente un oggetto o non lo elimineranno quando l'ultimo riferimento quando viene distrutto, C e C ++ hanno anche atomicvariabili integrate nel linguaggio, con operazioni atomiche garantite per far rispettare determinati tipi di coerenza della memoria se usate correttamente. MPI limita la comunicazione tra processi a messaggi espliciti e OpenMP ha una sintassi per garantire che l'accesso a variabili da thread diversi sia sicuro.

  • La proprietà che la memoria non perderà mai è spesso chiamata safe-for-space. La garbage collection automatica è una caratteristica della lingua per garantire ciò.

  • Molte lingue hanno la garanzia che le sue operazioni avranno risultati ben definiti e che i suoi programmi saranno ben educati. Come il supercat ha fornito un esempio di quanto sopra, C fa questo per l'aritmetica senza segno (garantito per essere avvolto in modo sicuro) ma non per l'aritmetica firmata (dove l'overflow è autorizzato a causare bug arbitrari, poiché C aveva bisogno di supportare CPU che fanno cose completamente diverse quando firmano l'aritmetica trabocca), ma a volte la lingua converte silenziosamente quantità non firmate in quantità firmate.

  • I linguaggi funzionali hanno un gran numero di invarianti che qualsiasi programma ben formato garantisce, ad esempio, che le funzioni pure non possano causare effetti collaterali. Questi possono o meno essere descritti come "sicuri".

  • Alcune lingue, come SPARK o OCaml, sono progettate per facilitare la dimostrazione della correttezza del programma. Ciò può essere o meno descritto come "sicuro" da bug.

  • Prove che un sistema non può violare un modello di sicurezza formale (da cui la battuta "Qualsiasi sistema che sia dimostrabilmente sicuro probabilmente non lo è.")


1
Ciò può essere o meno descritto come "sicuro" da bug. La prego di elaborare un po 'questo? Cosa intendi con "da bug"?
scaaahu,

2
@scaaahu Ecco un esempio di un sito Web che fa riferimento al software formalmente dimostrato come "dimostrabilmente sicuro". In questo contesto, si riferisce al software per prevenire la collisione degli aeromobili, quindi significa sicuro dalle collisioni.
Davislor,

1
Accetto questa risposta perché elenca i tipi di sicurezza. Il tipo che avevo in mente è la sicurezza della memoria.
Beroal,

Mentre questa risposta elenca alcuni link utili e molti esempi, la maggior parte di essi è completamente incasinata. La garbage collection assicura che la memoria non perda mai o che non utilizzi i blocchi "non sicuri" ti dà automaticamente sicurezza o overflow firmato essendo un comportamento indefinito perché i compilatori С devono supportare alcune strane CPU, sul serio? E solo una breve parola per Ada / SPARK che è l'unica delle lingue menzionate che prende sul serio la sicurezza.
VTT

93

Non esiste una definizione formale di "linguaggio di programmazione sicuro"; è una nozione informale. Piuttosto, le lingue che affermano di fornire sicurezza di solito forniscono una dichiarazione formale precisa del tipo di sicurezza che viene richiesto / garantito / fornito. Ad esempio, la lingua potrebbe fornire sicurezza dei tipi, sicurezza della memoria o altre garanzie simili.


13
Come addeumdum, se parliamo di C vs Java come il post di OP: è la sicurezza della memoria che è garantita in Java e non in C. La sicurezza del tipo è fornita da entrambi a modo loro. (Sì, molte persone che leggono questo già lo sanno, ma forse alcuni non lo sanno).
Walfrat,

17
@Walfrat Fa parte di questo. Java inoltre non ha un comportamento indefinito, cosa che ci aspettiamo da un linguaggio che si definisce "sicuro". Per quanto riguarda i sistemi di tipo, non credo che un forte sistema di tipo statico sia ciò che le persone tendono a intendere con "sicuro". Dopotutto, i linguaggi tipicamente dinamici come Python sono generalmente "sicuri".
Max Barraclough,

2
La mia definizione di sicurezza del tipo è il controllo della compilazione che lo gestisce. Questa potrebbe non essere la definizione formale. Si noti che ho detto "tipo di sicurezza", non "sicuro". Per me il linguaggio "sicuro" si riferisce alla "mia" definizione di "tipo e sicurezza della memoria" e penso che possa essere il più diffuso. Ovviamente non sto parlando di alcuni trabocchetti come la riflessione / il puntatore del vuoto in C che la compilazione non può gestire. Un'altra possibile definizione di sicuro è un programma che non si arresta in modo anomalo con un errore di segmento come il puntatore unitizzato in C. Cose del genere sono generalmente concesse in Python e Java.
Walfrat,

7
@Walfrat Tutto ciò che ti colpisce è una lingua in cui la sintassi è ben definita. Non garantisce che l' esecuzione sia ben definita e il numero di volte in cui ho visto un crash di JRE, posso dirti chiaramente che come sistema non è "sicuro". D'altra parte, in MISRA si è lavorato per evitare comportamenti indefiniti per ottenere un sottoinsieme più sicuro del linguaggio e la compilazione di C in assemblatore è molto meglio definita. Quindi dipende da ciò che consideri "sicuro".
Graham,

5
@MaxBarraclough - "Anche Java non ha un comportamento indefinito" - Java non ha un comportamento indefinito nel senso utilizzato nelle specifiche C nella definizione della lingua (sebbene consenta ad alcuni codici di produrre valori che non hanno un singolo valore predefinito, ad es. L'accesso una variabile che viene modificata in un altro thread o accedendo a doubleo longmentre viene modificata in un altro thread, che non è garantito per non produrre metà di un valore miscelato in un modo non specificato con metà di un altro) ma la specifica API tuttavia ha un comportamento indefinito in alcuni casi.
Jules,

41

Se riesci a mettere le mani su una copia dei tipi e dei linguaggi di programmazione di Benjamin Pierce , nell'introduzione, ha una buona panoramica di varie prospettive sul termine "linguaggio sicuro".

Una proposta di interpretazione del termine che potresti trovare interessante è:

"Una lingua sicura è completamente definita dal suo manuale del programmatore". Lascia che la definizione di una lingua sia l'insieme di cose che il programmatore deve comprendere per prevedere il comportamento di ogni programma nella lingua. Quindi il manuale per un linguaggio come C non costituisce una definizione, dal momento che il comportamento di alcuni programmi (ad esempio quelli che coinvolgono accessi di array non controllati o aritmetica del puntatore) non può essere previsto senza conoscere i dettagli di come un particolare compilatore C espone strutture in memoria , ecc., e lo stesso programma può avere comportamenti abbastanza diversi quando eseguito da compilatori diversi.

Quindi, esiterei a usare il termine "non sicuro" per fare riferimento a un'implementazione del linguaggio di programmazione. Se un termine indefinito in una lingua produce un comportamento diverso in diverse implementazioni, una delle implementazioni potrebbe comportare comportamenti che potrebbero essere più attesi, ma non lo definirei "sicuro".


7
Il problema di Halting ovviamente dice che, indipendentemente dalla lingua, ci saranno sempre programmi il cui comportamento non è prevedibile dalla definizione della lingua. Quindi ogni definizione che si basa su "prevedere il comportamento di ogni programma nella lingua" è fondamentalmente errata per qualsiasi lingua completa di Turing.
MSalters,

15
@MSalters Questo è un malinteso popolare sul problema dell'arresto. L'indecidibilità del problema di arresto implica che è impossibile derivare meccanicamente il comportamento di un programma arbitrario in un linguaggio completo di Turing. Ma è possibile che per ogni dato programma, il comportamento sia prevedibile. È solo che non puoi creare un programma per computer che faccia questa previsione.
Gilles 'SO- smetti di essere malvagio' il

7
@Giles: Non è così. Supponiamo che esista una prova di non cessazione per ogni programma non terminante. Quindi puoi enumerare le prove di non terminazione per scoprire se un determinato programma si interrompe. Quindi il problema di arresto è decidibile. Contraddizione. Pertanto, alcuni programmi non terminanti non sono di fatto non definitivi.
Kevin,

9
@Gilles: Sono perfettamente consapevole del fatto che molti programmi hanno banalmente dimostrato di fermarsi o meno. Ma la dichiarazione qui è letteralmente sul comportamento di ogni programma. La dimostrazione del teorema di Halting mostra che esiste almeno un programma per il quale ciò non è vero. È solo una prova non costruttiva, non ti dirà quale programma è indecidibile.
Salterio

8
@MSalters Penso che il bit implicito sia che l'affermazione riguarda il comportamento su piccola scala del programma, piuttosto che il comportamento emergente su larga scala. Ad esempio, prendi la congettura di Collatz . I singoli passaggi dell'algoritmo sono semplici e ben definiti, ma il comportamento emergente (quante iterazioni fino all'arresto, e se lo fa affatto), è tutt'altro. - "Predict" viene utilizzato in modo informale qui. Potrebbe essere meglio scritto come "sapere come verrà eseguita una determinata istruzione in un programma arbitrario".
RM,

18

Sicuro non è binario, è un continuum .

Informalmente parlando, la sicurezza si intende dall'opposizione ai bug, i 2 più spesso citati sono:

  • Sicurezza della memoria: il linguaggio e la sua implementazione impediscono una varietà di errori relativi alla memoria come l'uso dopo l'uso, doppio libero, fuori limite, ...
  • Sicurezza del tipo: il linguaggio e la sua implementazione impediscono una varietà di errori relativi al tipo come caselle non controllate, ...

Quelle non sono le uniche classi di bug che le lingue impediscono, la libertà della corsa dei dati o la libertà dello stallo è piuttosto desiderabile, le prove della correttezza sono piuttosto dolci, ecc ...

Raramente i programmi semplicemente errati sono considerati "non sicuri" (solo buggy) e il termine sicurezza è generalmente riservato alle garanzie che incidono sulla nostra capacità di ragionare su un programma. Pertanto, C, C ++ o Go, con comportamento indefinito, non sono sicuri.

E, naturalmente, ci sono lingue con sottoinsiemi non sicuri (Java, Rust, ...) che delineano intenzionalmente le aree in cui lo sviluppatore è responsabile del mantenimento delle garanzie linguistiche e il compilatore è in modalità "hands-off". Le lingue sono ancora generalmente soprannominate sicure , nonostante questo trampolino di fuga, una definizione pragmatica.


7
Direi che è una grata.
PatJ,

1
La maggior parte delle implementazioni dei linguaggi di programmazione ha funzionalità non sicure (ad es. Obj.magicIn Ocaml). E in pratica, questi sono davvero necessari
Basile Starynkevitch,

4
@BasileStarynkevitch: Davvero. Penserei che qualsiasi linguaggio con FFI contenga necessariamente un certo livello di non sicuro, poiché la chiamata di una funzione C richiederà il "pining" di oggetti GC e assicurerà manualmente che le firme su entrambi i lati coincidano.
Matthieu M.

15

Anche se non sono in disaccordo con la risposta di DW, penso che lasci una parte di "sicura" senza indirizzo.

Come notato, ci sono più tipi di sicurezza promossi. Credo che sia bene capire perché ci sono più nozioni. Ogni nozione è associata all'idea che i programmi soffrano soprattutto di una certa classe di bug e che i programmatori non sarebbero in grado di fare questo specifico tipo di bug se la lingua impedisse al programmatore di farlo.

Va notato che queste diverse nozioni hanno quindi diverse classi di bug e queste classi non si escludono a vicenda né coprono tutte le forme di bug. Solo per prendere i 2 esempi di DW, la domanda se una determinata posizione di memoria contiene un determinato oggetto è sia una questione di sicurezza del tipo che di memoria.

Un'ulteriore critica ai "linguaggi sicuri" deriva dall'osservazione che vietare determinati costrutti ritenuti pericolosi lascia al programmatore la necessità di trovare alternative. Empiricamente, la sicurezza è raggiunta meglio da buone biblioteche. l'utilizzo di codice già testato sul campo ti evita di creare nuovi bug.


10
È piuttosto fuori tema per questo sito, perché l'ingegneria del software non è in realtà una scienza, ma non sono d'accordo con la tua affermazione empirica. L'uso di buone librerie non ti salverà in lingue non sicure, perché non sei protetto dall'utilizzarle in modo errato. Le lingue sicure ti consentono di ottenere più garanzie dall'autore della biblioteca e di ottenere maggiori garanzie che le stai usando correttamente.
Gilles 'SO- smetti di essere malvagio' il

3
Sono con MSalters su questo. - "Le lingue sicure ti consentono di ottenere più garanzie dall'autore della biblioteca e ti consentono di ottenere maggiori garanzie che le stai usando correttamente." Questo non è un sequitur per tutti gli scopi pratici.
Capitan Giraffe

9

Una differenza fondamentale tra C e Java è che se si evitano alcune caratteristiche facilmente identificabili di Java (ad esempio quelle nello Unsafespazio dei nomi), ogni possibile azione che si possa tentare - comprese quelle "errate" - avrà una gamma limitata di possibili esiti . Mentre questo limita ciò che si può fare in Java - almeno senza usare lo Unsafespazio dei nomi, rende anche possibile limitare il danno che può essere causato da un programma errato, o - soprattutto - da un programma che dovrebbe elaborare correttamente file validi ma non particolarmente protetti da file errati.

Tradizionalmente, i compilatori C elaborano molte azioni in modo definito dallo standard in casi "normali", mentre elaborano molti casi angolari "in un modo caratteristico dell'ambiente". Se si stesse usando una CPU che si sarebbe messa in corto circuito e avrebbe preso fuoco se si fosse verificato un overflow numerico e si fosse voluto evitare che la CPU prendesse fuoco, sarebbe necessario scrivere un codice per evitare un overflow numerico. Se, tuttavia, si stesse utilizzando una CPU che avrebbe troncato perfettamente i valori secondo il complemento a due, non si sarebbe dovuto evitare traboccamenti nei casi in cui tale troncamento avrebbe comportato comportamenti accettabili.

La moderna C fa un passo avanti: anche se si sta prendendo di mira una piattaforma che definirebbe naturalmente un comportamento per qualcosa come un overflow numerico in cui lo Standard non impone requisiti, l'overflow in una parte di un programma può influire sul comportamento di altre parti del programma in modo arbitrario non vincolato dalle leggi del tempo e della causalità. Ad esempio, considera qualcosa come:

 uint32_t test(uint16_t x)
 {
   if (x < 50000) foo(x);
   return x*x; // Note x will promote to "int" if that type is >16 bits.
 }

Un compilatore C "moderno", dato qualcosa di simile a quanto sopra, potrebbe concludere che, poiché il calcolo di x * x trabocca se x è maggiore di 46340, può eseguire la chiamata a "pippo" incondizionatamente. Si noti che anche se sarebbe accettabile terminare in modo anomalo un programma se x è fuori portata o se la funzione restituisce qualsiasi valore in questi casi, chiamare foo () con una fuori portata x potrebbe causare danni ben oltre una di queste possibilità. Il C tradizionale non fornirebbe alcun equipaggiamento di sicurezza oltre a quello fornito dal programmatore e dalla piattaforma sottostante, ma consentirebbe agli equipaggiamenti di sicurezza di limitare il danno da situazioni impreviste. La moderna C aggirerà qualsiasi attrezzatura di sicurezza che non sia efficace al 100% nel mantenere tutto sotto controllo.


3
@DavidThornley: forse il mio esempio era troppo sottile. Se intè 32 bit, xverrà promosso a firmato int. A giudicare dalla logica, della norma gli autori si aspettavano che le implementazioni non strane avrebbe trattato firmato e tipi senza segno equivalente di moda al di fuori di alcuni casi specifici, ma gcc volte "ottimizza" in modo che si rompono se un uint16_tdai uint16_trendimenti si moltiplicano un risultato al di là INT_MAX , anche quando il risultato viene utilizzato come valore senza segno.
supercat

4
Buon esempio. Questo è uno dei motivi per cui dovremmo sempre compilare (su GCC o Clang) -Wconversion.
Davislor,

2
@Davislor: Ah, ho appena notato che godbolt ha invertito l'ordine in cui sono elencate le versioni del compilatore, quindi selezionando l'ultima versione di gcc nella lista si ottiene l'ultima piuttosto che la prima. Non penso che l'avvertimento sia particolarmente utile poiché è incline a contrassegnare molte situazioni come quelle return x+1;che non dovrebbero essere problematiche, e trasmettere il risultato a uint32_t soffocerebbe il messaggio senza risolvere il problema.
supercat

2
@supercat L'eliminazione dei test non ha senso se il compilatore è tenuto a rimettere i test in un posto diverso.
user253751

3
@immibis: una direttiva "verificato assume" può consentire a un compilatore di sostituire molti test o un controllo che verrebbe eseguito più volte all'interno di un loop, con un singolo test che potrebbe essere sollevato all'esterno di un loop. È meglio che richiedere ai programmatori di aggiungere controlli che non sarebbero necessari nel codice macchina affinché un programma soddisfi i requisiti, allo scopo di garantire che un compilatore non "ottimizzi" i controlli necessari per soddisfare i requisiti.
supercat

7

Esistono diversi livelli di correttezza in una lingua. In ordine di crescente astrazione:

  • Pochi programmi sono privi di errori (solo quelli per i quali può essere dimostrata la correttezza). Altri hanno già affermato che il contenimento degli errori è quindi l'aspetto di sicurezza più concreto. I linguaggi che girano in una macchina virtuale come Java e .net sono generalmente più sicuri a questo proposito: gli errori del programma vengono normalmente intercettati e gestiti in modo definito. 1
  • Al livello successivo, gli errori rilevati in fase di compilazione anziché in fase di esecuzione rendono una lingua più sicura. Un programma sintatticamente corretto dovrebbe anche essere semanticamente corretto il più possibile. Ovviamente il compilatore non può conoscere il quadro generale, quindi questo riguarda il livello di dettaglio. I tipi di dati forti ed espressivi sono un aspetto della sicurezza a questo livello. Si potrebbe dire che la lingua dovrebbe rendere difficile fare alcuni tipi di errori(errori di tipo, accesso non associato, variabili non inizializzate ecc.). Le informazioni sul tipo di runtime come gli array che contengono informazioni sulla lunghezza evitano errori. Ho programmato Ada 83 al college e ho scoperto che un programma Ada compilante conteneva in genere forse un ordine di grandezza meno errori rispetto al corrispondente programma C. Prendi semplicemente la capacità di Ada di definire i tipi interi che non sono assegnabili senza conversione esplicita: intere navi spaziali si sono schiantate perché piedi e metri erano confusi, cosa che si potrebbe banalmente evitare con Ada.

  • Al livello successivo, la lingua dovrebbe fornire i mezzi per evitare il codice della caldaia. Se devi scrivere i tuoi contenitori, o il loro smistamento, o la loro concatenazione, o se devi scrivere i tuoi string::trim(), commetterai degli errori. Poiché il livello di astrazione aumenta, questo criterio coinvolge sia la lingua corretta sia la libreria standard della lingua.

  • In questi giorni la lingua dovrebbe fornire mezzi per la programmazione concorrente a livello linguistico. La concorrenza è difficile da ottenere e forse impossibile da eseguire correttamente senza il supporto linguistico.

  • Il linguaggio dovrebbe fornire mezzi per la modularizzazione e la collaborazione. I tipi forti, elaborati e definiti dall'utente dall'alto aiutano a creare API espressive.

In qualche modo ortogonalmente la definizione della lingua dovrebbe essere comprensibile; la lingua e le biblioteche dovrebbero essere ben documentate. La documentazione difettosa o mancante porta a programmi cattivi e sbagliati.


1 Ma poiché di solito non è possibile dimostrare la correttezza della macchina virtuale, tali linguaggi potrebbero paradossalmente non essere adatti a requisiti di sicurezza molto rigidi.


1
+1 Per una chiara spiegazione strato per strato. Una domanda per te, intere navi spaziali si sono schiantate perché piedi e metri erano confusi, cosa che si potrebbe banalmente evitare con Ada. , stai parlando di Mars Probe Lost a causa di un semplice errore matematico ? Ti capita di conoscere la lingua che stavano usando per quella nave spaziale?
scaaahu,

2
@scaaahu Sì, penso di riferirmi a quello. No, non conosco la lingua. In realtà, leggendo il rapporto, sembra che i dati inviati dalla sonda siano stati elaborati dal software sulla terra producendo un file di dati che è stato quindi utilizzato per determinare i livelli di spinta. La semplice digitazione della lingua non è applicabile in questo scenario. A proposito, hanno avuto diversi problemi con il software di terra e il formato del file di dati, una confusione che ha impedito il rilevamento tempestivo del problema. Quindi la storia non è un'argomentazione diretta per la tipizzazione forte, ma è comunque un ammonimento.
Peter - Ripristina Monica il

1

Per favore, non dire che ogni PL ha comandi non sicuri. Possiamo sempre prendere un sottoinsieme sicuro.

Ogni lingua che conosco ha modi di scrivere programmi illegali che possono essere (compilati ed) eseguiti. E ogni lingua che conosco ha un sottoinsieme sicuro. Allora, qual è la tua domanda?


La sicurezza è multidimensionale e soggettiva.

Alcune lingue hanno molte operazioni "non sicure". Altri hanno meno operazioni di questo tipo. In alcune lingue, il modo predefinito di fare qualcosa è intrinsecamente pericoloso. In altri, il modo predefinito è sicuro. In alcune lingue, esiste un sottoinsieme esplicito "non sicuro". In altre lingue, questo sottoinsieme non esiste affatto.

In alcune lingue, "sicurezza" si riferisce esclusivamente alla sicurezza della memoria, un servizio offerto dalla libreria standard e / o dal runtime in cui le violazioni dell'accesso alla memoria sono rese difficili o impossibili. In altre lingue, "sicurezza" include esplicitamente la sicurezza del thread. In altre lingue, "sicurezza" si riferisce alla garanzia che un programma non si arresti in modo anomalo (un requisito che include il non consentire eccezioni non rilevate di alcun tipo). Infine, in molte lingue "sicurezza" si riferisce alla sicurezza dei tipi - se il sistema dei tipi è coerente in certi modi, si dice che sia "solido" (per inciso, Java e C # non hanno sistemi di tipo completamente sani).

E in alcune lingue, tutti i diversi significati di "sicurezza" sono considerati sottoinsiemi di sicurezza del tipo (ad es. Rust e Pony raggiungono la sicurezza del filo attraverso le proprietà del sistema di tipi).


-1

Questa risposta è un po 'più ampia. Negli ultimi decenni le parole sicurezza e sicurezza sono state mutilate da alcune parti della società di lingua inglese orientate politicamente, in modo tale che il loro uso comune non ha quasi alcuna definizione. Tuttavia, per i soggetti tecnici torno ancora a definire "sicurezza" e "sicuro" come: un dispositivo che impedisce l'uso involontario di qualcosa o che rende sostanzialmente più difficile l'uso accidentale e lo stato di essere sotto la protezione di tale dispositivo .
Quindi un linguaggio sicuro ha qualche dispositivo per limitare una particolare classe di bug. Naturalmente i limiti derivano da inconvenienti o addirittura incapacità in alcuni casi, e ciò non significa che le lingue "non sicure" provochino bug. ad esempio, non ho tappi di sicurezza sulle forcelle e per decenni sono riuscito, senza troppi sforzi, a evitare di accoltellare l'occhio mentre mangiavo. Certamente meno sforzo di quanto sarebbe stato speso usando i tappi. Quindi la sicurezza ha un costo in base al quale deve essere valutata. (la forcella di sughero è un riferimento a un personaggio di Steve Martin)

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.