[Allegro] a30 / Parallelen zwischen FLEX und JOB

[Thomas Berger]

Lieber Herr Eversberg,

>> ... Wenn konkret im Flex ein isoliertes
>>
>> sleep
>>
>> steht, dann ist das zur Laufzeit nur dann korrekt, wenn in der
>> iV eine Zahl steht...
> Na gut, speziell dieses läßt sich leicht machen. Wir setzen da eine
> 1, wenn es nicht der Fall ist.

Gerade das nicht, bzw. hoechstens "0", weil der (allegro-)uebliche
Extraktionsmechanismus fuer Zahlen aus Zeichenketten das tut (Flex-
Programmierung soll ja gerade nicht C++-Programmierung sein, daher
sind Automatismen, die Zeichenketten in Zahlen umwandeln etc. durchaus
in Ordnung).

Der Kontext der Bemerkung war aber derjenige, dass das Argument fuer
sleep zwar nur eine Zahl mit maximal etwas ueber 20 Vorkommastellen
sein /darf/, dafuer aber vorbereitetend die tendenziell 2MB grosse
iV in einen 255 Zeichen fassenden Speicherbereich umkopiert wird.
Das /sollte/ ausreichen, aber wer garantiert das? Gewiss ist in
so einer Situation irgendwo vorher ein Fehler geschehen, das geht
dann 1.000 mal gut, weil der Schrott in der iV zufaellig kuerzer
ist als 255 Zeichen, noch 1.000 mal, weil "wenig" ueberschrieben
wurde und das bis Laufzeitende von acon nicht auffaellt und
uebernaechstes Jahr crasht die Sache dann: Man denke an einen per HTTP
herbeigeholten JSON-Text, ab und zu enthaelt die iV nicht das
erwartete "[100]", sondern eine mittelgrosse HTML-Datei mit HTTP-
Fehlermeldung, weil auf irgendeinem fremden Server temporaer etwas
in Unordnung ist: Natuerlich ist der Flex letztendlich dafuer
verantwortlich, solche Faelle abzufangen, aber die Laufzeitumgebung
/muss/ das Gesamtsystem und insbesondere die Datenbank schuetzen,
der Amok laufende Flex richtet u.U. selbst schon genug Schaden an,
das darf niemals durch Ueberschreiben interner Datenstrukturen
verstaerkt werden.


> Aber ganz pauschal
>> Man darf nicht davon ausgehen, dass der Flex
>> absolut korrekt programmiert ist.
> ist zwar völlig richtig, und natürlich ist uns das klar, aber das ist
> keine konkret umsetzbare Spezifikation, sondern eben ein Prinzip. Und
> ein solches läßt sich mal mehr und mal weniger real umsetzen. Sicher
> öfter als wir es tun, schon klar.
> 
> Sie zwinkern dann ja auch ganz zutreffend bei der Maximalforderung
>> die Laufzeitumgebung fuer FLEX muss auf
>> wirklich alles gefasst sein (insbesondere auf mehr als das
>> Antizipierbare ;-).
> Und was das anlangt, wird unser Vorstellungsvermögen ja regelmäßig
> übertroffen.

Ja, und daher muss einfach, stur und voellig phantasielos alles
vor Ueberlaeufen geschuetzt werden, auch wenn man sich nicht
vorstellen kann, wie so etwas passieren koennte. Oder man macht
sich die Muehe zu /beweisen/, dass ein bestimmter Zustand nicht
erreicht werden kann, weil ein vorigen Test ihn bereits abgefangen
hat. Und selbst das wird normalerweise codiert ("Panic: Assertion
failed!") mit sofortigem Abbruch von allem

viele Gruesse
Thomas Berger