Reinhard Irmer <[EMAIL PROTECTED]> wrote on 18.04.04:
> Michael Heydekamp <[EMAIL PROTECTED]> schrieb:
> [...]
>>>> Das war weniger eine Vermutung als mehr gesichertes Wissen.
>>>> Schlie�lich wei� ich es ja auch vom Programmierer selbst.
>>> Das haettest Du mir auch eher sagen koennen,
>> Ja gut, ich hatte geschrieben:
>> ----------8<----------
>> Vorsicht - damit kann es Probleme geben. Entweder ist die
> ^^^^^^ muss aber nicht ?
Richtig. Wenn gar keine Zeilen > 255 Zeichen vorkommen, dann schneidet
XP3P nat�rlich auch nix ab.
>> Unterstuetzung langer Zeilen > 255 Zeichen aktiviert,
>> dann kann XP3P schon mal abstuerzen.
> ^^^^^^^ mu� aber nicht ?
N�. Wenn das von Johann beschriebene Szenario (das ja nicht die Regel
ist) nicht eintritt, st�rzt die Nicht-Abschneideversion auch nicht ab.
>> Oder sie ist deaktiviert, dann stuerzt XP3P nicht ab, kappt aber
>> mitunter Zeilen > 255 Zeichen.
> ^^^^^^^^ =vermutlich?
"Mitunter" als "vermutlich" zu �bersetzen, ist etwas sehr frei. Diese
Einschr�nkung habe ich nur gemacht, weil ich das Problem nicht aus
eigener Anschauung, sondern nur aus Berichten anderer kenne. Ich wei�
also auch bis jetzt nicht, ob es nicht auch Szenarien gibt, bei denen
Zeilen > 255 Zeichen nicht abgeschnitten werden - was je nach
Beschaffenheit des RFC-Puffers durchaus m�glich ist.
>> Mal grob aus der Erinnerung, Naeheres kann Robo ([EMAIL PROTECTED]) Dir
>> erklaeren. Ursache ist ein Bug im Compiler, den der Entwickler bis
>> heute wohl nicht behoben hat.
> ^^^^^^ das Wort web, und es ist eindeutig
>> ----------8<----------
Das kann ich aber nicht wegnehmen, denn was wei� ich, ob der Entwickler
(des Compilers) den Bug inzwischen behoben hat - das m��test Du wie
gesagt Robo fragen. Die letzte Info von ihm dazu (mir gegen�ber) liegt
mehrere Monate oder sogar ca. ein Jahr zur�ck.
Tatsache ist aber, da� er zum Zeitpunkt, als Dein XP3P compiliert wurde,
nicht behoben war.
>> Die ersten beiden Abs�tze sind eigentlich nicht wie eine Vermutung
>> formuliert
> Doch ;-)
S.o., sie sind nur bewu�t vorsichtig formuliert, um keine falschen
Aussagen zu machen. Die Existenz der Probleme als solche stand nie in
Frage, die genauen Umst�nde kann ich mangels eigener Tests auch jetzt
noch nicht exakt beschreiben.
[...]
>> Insofern war das hier ein sch�nes Beispiel daf�r, wie man es machen
>> sollte.
> Aber nicht zu oft ;)
Ich wei�, es ist Arbeit. Gehe mal davon aus, da� ich bei jeder �nderung
im UUZ, mir mehrere solcher Szenarien ausdenken, erstellen und testen
mu�.
Das Problem bei Programmen, die eine Stringl�ngenbegrenzung haben, aber
durch entprechenden Code diese aufheben sollen (siehe das Schreiben
unbegrenzt langer Zeilen im Body, wie es der Enhanced UUZ von FreeXP
macht), sind immer die Grenzf�lle.
Alle UUZ-Routinen arbeiten mit 253 Zeichen langen Strings, und solange
die Strings k�rzer oder l�nger sind, ist alles OK. Genauer unter die
Lupe nehmen mu� man aber die F�lle, in denen an Pos. 253 bis 256
bestimmte Umst�nde zutreffen - z.B. wenn man die typischen zwei
Leerzeichen, die der XP-Editor bei fortlaufend umbrochenen Abs�tzen am
Ende jeder Zeile hinterl��t, bei der UUZ-Konvertierung entfernen will.
Wenn die genau an Pos. 253/254 oder Pos. 254/255 liegen, kann ich das in
dem Moment, wo ich nur die ersten 253 Zeichen in der String-Variablen
habe, nicht sehen. Ich mu� es aber wissen, um bestimmte Entscheidungen
treffen zu k�nnen.
Also mu� man f�r diese F�lle wieder eine Sonderbehandlung vornehmen
(praktisch in die folgenden Bytes reingucken, sofern sie existieren und
man dran kommt), weil die ganze restliche Logik der Routine sonst
ausgetrickst und die Nichtbeachtung dieser F�lle zu unerw�nschten
Ergebnissen f�hren k�nnte (hier wieder "k�nnte", weil es in allen
anderen F�llen ja wieder funktionieren w�rde).
Das sind dann so die Bugs, die jahrelang unbemerkt bleiben k�nnen, bis
irgendwann der erste genau das Szenario erwischt hat, das zu einem
Problem f�hrt.
Das Nachdenken dar�ber, welche F�lle auftreten und welche davon zu einem
Problem f�hren k�nnen und daher gesondert behandelt werden m�ssen, ist
mit das Wichtigste beim Entwickeln. Und wurde, wie ich an alten
Routinen sehen kann, nicht immer in ausreichendem Ma�e gepflegt.
Aber ich denke, da� diese restlichen auch noch im Enhanced UUZ
befindlichen Nachl�ssigkeiten fr�herer Jahre mit der n�chsten Version
eliminiert sein werden. Bis mich der n�chste Bugreport in zwei Jahren
eines Besseren belehrt. ;)
Michael
------------------------------------------------------------------------
FreeXP Support-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/support-list
