Was sind die Sicherheitsvorteile eines Typsystems?


47

In JavaScript: The Good Parts von Douglas Crockford erwähnt er in seinem Vererbungskapitel:

Der andere Vorteil der klassischen Vererbung besteht darin, dass sie die Spezifikation eines Typensystems umfasst. Dies befreit den Programmierer größtenteils davon, explizite Casting-Operationen schreiben zu müssen, was sehr gut ist, da beim Casting die Sicherheitsvorteile eines Typsystems verloren gehen.

Was ist eigentlich Sicherheit? Schutz vor Datenkorruption, Hackern, Systemstörungen etc.?

Was sind die Sicherheitsvorteile eines Typsystems? Was unterscheidet ein Typensystem, das diese Sicherheitsvorteile bietet?


Ich bin nicht sicher, ob Typsysteme Vorteile für nicht kompilierte Sprachen bieten, aber als Langzeitbenutzer kompilierter Sprachen stelle ich fest, dass kompilierte Sprachen mit sorgfältiger Typüberprüfung viele Arten von mehrdeutigem, undefiniertem oder unvollständigem Code wirksam verhindern die Phase "Kompilieren" hinter sich lassen. Man könnte sagen, dass Tipptipps und ein Lint-System für Web-Scripting (JavaScript) wertvoll sind, und wenn ja, werden wir sicher genug davon sehen. Dart jemand? Dynamische Sprachen wie Python scheinen nicht schlechter zu sein, da es kein statisches Typsystem gibt.
Warren P

1
Heute verstehen wir, dass das Tippen verhaltensorientiert und nicht strukturell sein sollte. Leider haben die meisten modernen Programmiersprachen keine Möglichkeit, das Verhalten eines Typs zu bestätigen ( siehe diese Frage für eine gute Lektüre). Dies macht das Typsystem in den meisten Fällen ziemlich nutzlos, zumal einfache Tippfehler, die hier erwähnt werden, von einem cleveren Linter abgefangen werden können, der nach häufigen Problemen sucht.
Benjamin Gruenbaum

4
@BenjaminGruenbaum Was Ihre Beschreibung bereits in Sprachen wie OCaml statisch existiert. Es heißt strukturelle Typisierung, es ist eigentlich ziemlich alt, nominelle Typisierung ist neuer.
Jozefg

2
@BenjaminGruenbaum: ... was !? In statisch typisierten Sprachen ist es offensichtlich nicht unentscheidbar , sonst wäre es unmöglich, einen Compiler für diese Sprachen zu schreiben.
BlueRaja - Danny Pflughoeft

6
@BenjaminGruenbaum: Ihre Kommentare sind wertvoll, und dieses Papier ist interessant, aber es bestätigt nicht Ihre Behauptung, dass "es normalerweise auch in statischen Sprachen wie Java unentscheidbar ist", da es demonstriert, dass es in C # entscheidbar ist , und die Frage offen lässt ob es in Java unentscheidbar ist. (Und überhaupt, IME, wenn ein Compiler für eine statisch typisierte Sprache nicht entscheiden kann, dass etwas gut typisiert ist, lehnt er es ab (oder kompiliert es nicht), so dass Unentscheidbarkeit eher ein Ärger als eine Lücke in der Typisierung ist. Sicherheit.)
Ruakh

Antworten:


82

Typsysteme verhindern Fehler

Typsysteme eliminieren illegale Programme. Betrachten Sie den folgenden Python-Code.

 a = 'foo'
 b = True
 c = a / b

In Python schlägt dieses Programm fehl. es löst eine Ausnahme aus. In einer Sprache wie Java, C # oder Haskell ist dies nicht einmal ein legales Programm. Sie vermeiden diese Fehler vollständig, da sie in den Eingabeprogrammen einfach nicht möglich sind.

Ebenso schließt ein besseres Typsystem mehr Fehler aus. Wenn wir zu hochentwickelten Typsystemen aufsteigen, können wir Folgendes sagen:

 Definition divide x (y : {x : integer | x /= 0}) = x / y

Jetzt garantiert das Typensystem, dass es keine Division-durch-0-Fehler gibt.

Welche Art von Fehlern

Im Folgenden finden Sie eine kurze Liste der Fehler, die durch Systeme verhindert werden können

  1. Fehler außerhalb des Bereichs
  2. SQL-Injektion
  3. Verallgemeinert 2, viele Sicherheitsfragen (was Überprüfung taint ist in Perl )
  4. Fehler außerhalb der Reihenfolge (vergessen, init aufzurufen)
  5. Erzwingen der Verwendung einer Teilmenge von Werten (z. B. nur Ganzzahlen größer als 0)
  6. Schändliche Kätzchen (Ja, es war ein Witz)
  7. Präzisionsverlustfehler
  8. Software Transactional Memory (STM) -Fehler (dies erfordert Reinheit, die auch Typen erfordert)
  9. Generalisierung 8, Kontrolle der Nebenwirkungen
  10. Invarianten über Datenstrukturen (ist ein binärer Baum ausgeglichen?)
  11. Eine Ausnahme vergessen oder die falsche auslösen

Und denken Sie daran, dies ist auch zur Kompilierungszeit . Sie müssen keine Tests mit 100% Codeabdeckung schreiben, um einfach nach Tippfehlern zu suchen. Der Compiler erledigt dies nur für Sie :)

Fallstudie: Typisierte Lambda-Rechnung

Okay, lassen Sie uns das einfachste aller Typsysteme untersuchen, einfach Lambda-Kalkül .

Grundsätzlich gibt es zwei Arten,

Type = Unit | Type -> Type

Und alle Ausdrücke sind entweder Variablen, Lambdas oder Anwendungen. Auf dieser Grundlage können wir beweisen, dass jedes gut typisierte Programm beendet wird. Es gibt nie eine Situation, in der das Programm für immer hängen bleibt oder sich wiederholt. Dies ist im normalen Lambda-Kalkül nicht nachweisbar, da dies nicht der Fall ist.

Denken Sie darüber nach, wir können Typsysteme verwenden, um zu gewährleisten, dass unser Programm nicht für immer wiederholt wird, ziemlich cool, oder?

Abstecher in dynamische Typen

Dynamische Typsysteme können identische Garantien bieten wie statische Typsysteme, jedoch nicht zur Kompilierungszeit, sondern zur Laufzeit. Tatsächlich können Sie seit der Laufzeit mehr Informationen anbieten. Sie verlieren jedoch einige Garantien, insbesondere in Bezug auf statische Eigenschaften wie die Terminierung.

Dynamische Typen schließen also bestimmte Programme nicht aus, sondern leiten fehlerhafte Programme an genau definierte Aktionen weiter, z. B. das Auslösen von Ausnahmen.

TLDR

Das Lange und Kurze ist, dass Typsysteme bestimmte Programme ausschließen. Viele der Programme sind in irgendeiner Weise fehlerhaft, daher vermeiden wir bei Typsystemen diese fehlerhaften Programme.


25
+1 für das Kompilieren als Äquivalent zum Schreiben vieler Tests.
Dan Neely

3
@DanNeely Es soll lediglich veranschaulichen, dass Sie in einer dynamischen Sprache alle Teile des Codes ausführen müssen, um die Fehler zu erfassen, die ein Typensystem kostenlos überprüft. Und in einer abhängig getippten Sprache können Sie Tests tatsächlich vollständig durch Typen ersetzen.
Oft

3
Wenn Ihr Typsystem bewiesen hat, dass Ihr Programm beendet werden muss, geschieht dies (wahrscheinlich) durch den Nachweis, dass es eine primitiv-rekursive Funktion berechnet. Das finde ich cool, ist aber eine deutlich weniger interessante Komplexitätsklasse als die, die eine echte Turing-Maschine lösen kann. (Es bedeutet nicht, dass die Zwischenwerte nicht groß sind; die Ackermann-Funktion ist primitiv-rekursiv…)
Donal Fellows

5
@DonalFellows Die Ackermann-Funktion ist nicht primitiv rekursiv, obwohl es sich um eine vollständig berechenbare Funktion handelt.
Taymon

4
@sacundim Genau, Sprachen wie agda ermöglichen eine optionale Überprüfung der Gesamtheit. In den seltenen Fällen, in denen Sie eine willkürliche Rekursion wünschen, können Sie dies freundlich nachfragen.
Jozefg

17

Die Realität selbst ist getippt. Sie können keine Längen zu Gewichten hinzufügen. Und während Sie Meter mit Füßen versehen können (beide sind Längeneinheiten), sollten Sie mindestens eine der beiden skalieren. Andernfalls kann Ihre Mars-Mission buchstäblich abstürzen.

In einem typsicheren System wäre das Hinzufügen von zwei Längen in verschiedenen Einheiten entweder ein Fehler gewesen oder hätte eine automatische Umwandlung verursacht.


15

Ein Typensystem hilft Ihnen, einfache Codierungsfehler zu vermeiden, oder lässt den Compiler diese Fehler für Sie abfangen.

Beispielsweise wird in JavaScript und Python das folgende Problem häufig nur zur Laufzeit festgestellt - und je nach Testqualität / Seltenheit schafft es die Bedingung möglicherweise tatsächlich in die Produktion:

if (someRareCondition)
     a = 1
else
     a = {1, 2, 3}

// 10 lines below
k = a.length

Während eine stark typisierte Sprache Sie zwingt, explizit anzugeben, dass aes sich um ein Array handelt, können Sie keine Ganzzahl zuweisen. Auf diese Weise gibt es keine Chance, adie Sie nicht haben werden length- auch in den seltensten Fällen.


5
Und ein cleverer Linter in einer IDE wie WebStorm JavaScript kann "Möglicher undefinierter Verweis auf a.length für Nummer a" sagen. Dies ist uns nicht durch ein explizites Typensystem gegeben.
Benjamin Gruenbaum

4
1. Statisch nicht stark 2. @BenjaminGruenbaum Ja, aber dies geschieht durch Verfolgen eines Diagramms von Zuordnungen im Hintergrund. Stellen Sie es sich wie einen Mini-Interpreter vor, der versucht, herauszufinden, wohin die Dinge gehen. Viel schwieriger, als wenn die Typen es Ihnen kostenlos geben
jozefg

6
@BenjaminGruenbaum: Verwechsle nicht implizit / explizit mit stark / schwach. Haskell hat zum Beispiel ein unglaublich starkes Schriftsystem, das die meisten anderen Sprachen in den Schatten stellt, aber aufgrund bestimmter Entscheidungen im Hinblick auf das Sprachdesign ist es auch in der Lage, fast ausschließlich auf universelle Schriftsätze zu schließen, was es im Wesentlichen zu einer stark impliziten Schriftsprache mit Unterstützung für explizites Tippen macht (Das sollten Sie verwenden, weil der Typ Inferencer nur von dem, was Sie geschrieben haben, ableiten kann, nicht was Sie gemeint haben!)
Phoshi

6
„Stark typisierte Sprache zwingt Sie dazu, explizit anzugeben, dass a ein Array ist.“ Das ist falsch. Python ist stark typisiert und benötigt das nicht. Sogar statisch und stark typisierte Sprachen erfordern dies nicht, wenn sie Typinferenz unterstützen (und die meisten gängigen Sprachen heutzutage zumindest teilweise).
Konrad Rudolph

1
@BenjaminGruenbaum: Ah, fair genug. Trotzdem wird es Fälle geben, in denen kein statischer JS-Analysator die gleichen Arten von Typchecks ausführen kann, die eine stark typisierte Sprache liefern würde, um das Problem des Anhaltens im Allgemeinen zu lösen. Haskell musste einige wenige Entwurfsentscheidungen treffen, um eine nahezu 100% ige Typinferenz zu erzielen, und C # / Scala kann nicht alles ableiten. In diesen Fällen spielt es natürlich keine Rolle, da Sie nur explizit Typen angeben können. In Javascript bedeutet dies, dass selbst der beste statische Analysator Ihren Code nicht mehr überprüfen kann.
Phoshi

5

Je früher im Softwareentwicklungszyklus ein Fehler auftritt, desto günstiger ist die Fehlerbehebung. Stellen Sie sich einen Fehler vor, der dazu führt, dass Ihr größter Kunde oder alle Ihre Kunden Daten verlieren. Ein solcher Fehler könnte das Ende Ihres Unternehmens bedeuten, wenn er erst dann abgefangen wird, wenn echte Kunden Daten verloren haben! Es ist deutlich günstiger, diesen Fehler zu finden und zu beheben, bevor er in die Produktion verlagert wird.

Selbst bei weniger kostspieligen Fehlern wird mehr Zeit und Energie aufgewendet, wenn Tester beteiligt sind, als wenn Programmierer sie finden und beheben können. Es ist billiger, wenn es nicht in die Quellcodeverwaltung eingecheckt wird, wo andere Programmierer Software entwickeln können, die darauf basiert. Die Typensicherheit verhindert, dass bestimmte Fehlerklassen überhaupt kompiliert werden, und beseitigt so fast die gesamten potenziellen Kosten dieser Fehler.

Aber das ist nicht die ganze Geschichte. Wie jeder, der in einer dynamischen Sprache programmiert, Ihnen mitteilt, ist es manchmal schön, wenn Ihr Programm nur kompiliert wird, damit Sie einen Teil davon ausprobieren können, ohne jedes Detail herauszufinden. Es gibt einen Kompromiss zwischen Sicherheit und Komfort. Komponententests können das Risiko der Verwendung einer dynamischen Sprache etwas verringern, aber das Schreiben und Beibehalten guter Komponententests ist mit höheren Kosten verbunden als die Verwendung einer typsicheren Sprache.

Wenn Sie experimentieren, wenn Ihr Code nur einmal verwendet wird (z. B. ein einmaliger Bericht) oder wenn Sie sich in einer Situation befinden, in der Sie ohnehin keinen Komponententest schreiben würden, ist eine dynamische Sprache wahrscheinlich perfekt für dich. Wenn Sie eine große Anwendung haben und ein Teil ändern möchten, ohne den Rest zu beschädigen, ist Typensicherheit ein Lebensretter. Die Arten von Fehlern und Sicherheitsmechanismen sind genau die Arten von Fehlern, die Menschen beim Refactoring häufig übersehen oder falsch verstehen.


Dies verkauft Kurzformate für dynamisches Tippen, ohne die Hauptvorteile zu erwähnen (die genannten sind praktisch, wenn sie nicht wichtig sind). Es scheint auch etwas Seltsames an Unit-Tests zu implizieren - ja, sie sind schwer zu machen und kosten etwas, und das gilt auch für statisch typisierte Sprachen. Was versucht das zu sagen? Es werden auch die (konstruktionsbedingten) Einschränkungen aktueller Typsysteme nicht erwähnt, sowohl was sie ausdrücken können als auch welche Fehler sie abfangen können.

@MattFenwick Was sind Ihrer Meinung nach die Hauptvorteile des dynamischen Tippens?
GlenPeterson

Typische statische Systeme lehnen viele gut typisierte Programme ab. ( eine Alternative ) (Übrigens, meine Kritik richtete sich nur auf den 3. und 4. Absatz.)

4

Einführung

Die Typensicherheit kann entweder mit statisch typisierten (kompilierten, statischen Typprüfungen) und / oder Laufzeitsprachen (evaluierte, dynamische Typprüfungen) erreicht werden. Laut Wikipedia wird ein '... starkes Typsystem als eines beschrieben, bei dem es keine Möglichkeit für einen ungeprüften Laufzeitfehler gibt (ed Luca Cardelli). Mit anderen Worten, das Fehlen von ungeprüften Laufzeitfehlern wird als Sicherheit oder Typensicherheit bezeichnet ... “

Sicherheit - Statische Typprüfung

Typensicherheit ist seit jeher ein Synonym für statische Typisierung in Sprachen wie C, C ++ und Haskell, mit denen Typenkonflikte beim Kompilieren erkannt werden. Dies hat den Vorteil, dass potenziell undefinierte oder fehleranfällige Bedingungen bei der Ausführung des Programms vermieden werden. Dies kann von unschätzbarem Wert sein, wenn das Risiko besteht, dass Zeigertypen falsch zugeordnet werden, z. B. wenn eine Situation nicht erkannt wird, die zu katastrophalen Folgen führen kann. In diesem Sinne ist statisches Schreiben gleichbedeutend mit Speichersicherheit.

Die statische Eingabe ist nicht vollständig sicher, erhöht jedoch die Sicherheit . Selbst statisch typisierte Systeme können katastrophale Folgen haben. Viele Experten sind der Ansicht, dass statisch typisierte Systeme verwendet werden können, um robustere und weniger fehleranfällige (geschäftskritische) Systeme zu schreiben.

Statisch geschriebene Sprachen können dazu beitragen, das Risiko von Datenverlusten oder Genauigkeitsverlusten bei numerischen Arbeiten zu verringern, die durch falsches Anpassen oder Abschneiden von double-to-float oder falsches Anpassen von Integral- und Float-Typen auftreten können.

Die Verwendung statisch typisierter Sprachen bietet einen Vorteil hinsichtlich Effizienz und Ausführungsgeschwindigkeit. Die Laufzeit profitiert davon, dass die Typen während der Ausführung nicht ermittelt werden müssen.

Sicherheit - Laufzeitprüfung

Erlang ist beispielsweise eine typdeklarative, dynamisch typüberprüfte Sprache, die auf einer virtuellen Maschine ausgeführt wird. Erlang Code kann byteweise kompiliert werden. Erlang gilt als die vielleicht wichtigste geschäftskritische , fehlertolerante Sprache, und es wird berichtet, dass Erlang eine Zuverlässigkeit von neun Neunern (99,9999999% oder nicht mehr als 31,5 ms pro Jahr) aufweist.

Bestimmte Sprachen, wie z. B. Common Lisp, sind nicht statisch typisiert. Auf Wunsch können jedoch Typen deklariert werden, um die Geschwindigkeit und Effizienz zu verbessern. Es ist auch zu beachten, dass viele der am häufigsten verwendeten interpretierten Sprachen wie Python unterhalb der Evaluierungsschleife in statisch typisierten Sprachen wie C oder C ++ geschrieben sind. Sowohl Commom Lisp als auch Python gelten nach der obigen Definition als typsicher.


2
Ich widerspreche "stark getippt". Du meinst statisch getippt. Stark Typ hat so ziemlich keine Bedeutung, es wird im Grunde genommen verwendet, um zu sagen "Ich mag dieses
Typensystem

@ jozefg Guter Punkt. Ich werde den Beitrag ändern.
AsymLabs

3
Es ist auch nicht sinnvoll, interpretierte Sprache zu sagen ... über eine Sprachimplementierung ja, aber nicht die Sprache selbst. Jede Sprache kann interpretiert oder kompiliert werden. Und auch nach der Bearbeitung verwenden Sie die Begriffe starke und schwache Eingabe.
Esailija

3
@jozefg: Ich dachte immer, dass stark getippt bedeutet, dass jeder Wert einen festen Typ hat (z. B. Ganzzahl, Zeichenfolge usw.), während schwach getippt bedeutet, dass ein Wert in einen Wert eines anderen Typs umgewandelt werden kann, wenn dies als zweckmäßig erachtet wird damit. Beispiel: In Python (stark typisiert) wird 1 + "1"eine Ausnahme ausgelöst, während in PHP (schwach typisiert) eine Ausnahme 1 + "1"erzeugt wird 2(Zeichenfolge "1"wird automatisch in Ganzzahl konvertiert 1).
Giorgio

1
@Giorgio mit einer solchen Definition, zum Beispiel Java, ist nicht stark typisiert. In vielen Fällen wird dies jedoch behauptet. Diese Worte haben einfach keine Bedeutung. Stark / Schwach getippt haben eine viel genauere Definition als "Ich mag / nicht diese Sprache", wie Jozefg sagt.
Esailija

1

Die Sicherheitsvorteile eines Typsystems gehen verloren.

Was ist eigentlich Sicherheit? Schutz vor Datenkorruption, Hackern, Systemstörungen etc.?

Was sind die Sicherheitsvorteile eines Typsystems? Was unterscheidet ein Typensystem, das diese Sicherheitsvorteile bietet?

Ich habe das Gefühl, dass Typsysteme eine so negative Sichtweise haben. Bei einem Typensystem geht es mehr um eine Garantie als um den Nachweis der Fehlerfreiheit. Letzteres ist eine Konsequenz des Typsystems. Ein Typensystem für eine Programmiersprache ist eine Möglichkeit, beim Kompilieren den Beweis zu erbringen, dass ein Programm einer bestimmten Spezifikation entspricht.

Die Art der Spezifikation, die man als Typ codieren kann, hängt von der Sprache oder direkter von der Stärke des Typensystems der Sprache ab.

Die grundlegendste Art der Spezifikation ist eine Garantie für das Ein- / Ausgabeverhalten von Funktionen und die Gültigkeit des Inneren eines Funktionskörpers. Betrachten Sie einen Funktionsheader

f : (Int,Int) -> String

Ein gutes Typsystem stellt sicher, dass f nur auf Objekte angewendet wird, die bei der Auswertung ein Paar Int erzeugen, und garantiert, dass f immer eine Zeichenfolge erzeugt.

Einige Anweisungen in einer Sprache, wie If-Then-Blöcke, weisen kein Eingabe- / Ausgabeverhalten auf. hier garantiert das Typensystem, dass jede Deklaration oder Anweisung im Block gültig ist; Dies gilt für Operationen an Objekten der richtigen Art. Diese Garantien sind zusammensetzbar.

Dies gibt auch eine Art Speicher-Sicherheitsbedingung. Das Zitat, mit dem Sie es zu tun haben, handelt vom Casting. In einigen Fällen ist das Umwandeln in Ordnung, wie das Umwandeln eines 32-Bit-Int in ein 64-Bit-Int. Im Allgemeinen stürzt das Typsystem jedoch ab.

Erwägen

Foo x = new Foo(3,4,5,6);
f((Int)x,(Int)x);

Aufgrund des Castings wird x in ein Int umgewandelt. Es macht jedoch den Zweck der Typenkontrolle zunichte.

Eine Sache, die ein anderes und besseres Typensystem hervorbringen könnte, ist das Verbieten von Würfen (A) x, wobei x vor dem Fall Typ B ist, es sei denn, B ist ein Subtyp (oder Subobjekt) von A. Die Ideen der Subtypentheorie wurden in der Sicherheit verwendet um die Möglichkeit von Integer-Überlauf- / Unterlaufangriffen auszuschließen.

Zusammenfassung

Ein Typensystem ist eine Methode, um zu beweisen, dass ein Programm einer bestimmten Spezifikation entspricht. Welche Vorteile ein Typensystem bieten kann, hängt von der Stärke des verwendeten Typensystems ab.


1

Ein Vorteil, der für ein Typensystem noch nicht erwähnt wurde, liegt in der Tatsache, dass viele Programme mehr gelesen als geschrieben werden, und in vielen Fällen kann ein Typensystem ermöglichen, dass viele Informationen auf eine Weise spezifiziert werden, die kurz und einfach ist von jemandem verdaut, der den Code liest. Während Parametertypen keine beschreibenden Kommentare ersetzen, finden es die meisten Leute schneller zu lesen: "int Distance;" oderDistance As Int32als zu lesen "Abstand muss eine ganze Zahl +/- 2147483647 sein"; Das Übergeben von Brüchen kann zu inkonsistenten Ergebnissen führen. "Darüber hinaus können Parametertypen dazu beitragen, die Lücke zwischen dem, was eine bestimmte Implementierung einer API tut, und dem, worauf sich Aufrufer verlassen dürfen, zu verringern. Beispielsweise, wenn eine bestimmte JavaScript-Implementierung einer API verwendet seine Parameter in einer Weise , die keine Strings in numerische Form zwingen würde, kann es unklar sein , ob Anrufer auf ein solches Verhalten verlassen dürfen, oder wenn andere Implementierungen der API könnte Störung Strings , wenn angegeben. eine Methode , deren Parameter, wie angegeben DoubleWould Stellen Sie klar, dass alle Zeichenfolgenwerte vom Aufrufer erzwungen werden müssen, bevor sie übergeben werden. Verwenden Sie eine Methode mit einer Überladung, die akzeptiert, Doubleund eine andere, die akzeptiertString würde etwas klarer machen, dass Anrufer, die Zeichenfolgen halten, diese als solche weitergeben dürfen.


0

Was ist eigentlich Sicherheit? Schutz vor Datenkorruption, Hackern, Systemstörungen etc.?

Alle anderen Antworten und mehr. Im Allgemeinen bedeutet "Typensicherheit" einfach, dass keines der Programme, die ein Compiler erfolgreich kompiliert, Typfehler enthält.

Was ist nun ein Tippfehler? Grundsätzlich können Sie jede unerwünschte Eigenschaft als Typfehler angeben, und einige Typsysteme können statisch sicherstellen, dass kein Programm einen solchen Fehler aufweist.

Mit "Eigenschaft" oben meine ich eine Art logischen Satz, der für Ihr Programm gilt, z. B. "Alle Indizes liegen innerhalb der Arraygrenzen". Andere Arten von Eigenschaften umfassen: "Alle referenzierten Zeiger sind gültig", "Dieses Programm führt keine E / A aus" oder "Dieses Programm führt E / A nur nach / dev / null aus" usw. Fast jede Art von Abhängig von der Aussagekraft Ihres Typsystems kann auf diese Weise die Eigenschaft angegeben und der Typ überprüft werden.

Abhängige Typsysteme gehören zu den allgemeinsten Typsystemen, über die Sie so ziemlich jede Eigenschaft erzwingen können, die Sie möchten. Dies ist jedoch nicht unbedingt einfach, da anspruchsvolle Eigenschaften der Unvollständigkeit von Gödel unterliegen .

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.