Bug in UKAW1.88 oder in FreeXP-UUZ?

[Michael Heydekamp]

Hans-Juergen Taenzer <Hans-Juergen.Taenzer at t-online.de> wrote on 27.03.04:

> Michael Heydekamp (my-news at freexp.de) wrote:

>> Du könntest evtl. ein XPFILTER-Muster bauen, das in Headerzeilen
>> dieses Posters den String "?UTF-8?" durch "?ISO-8859-1?" ersetzt.
>> ;-)

> Das löst vermutlich nicht das Problem mit dem falschen LEN-Header.

Der etwas scherzhaft gemeinte Hinweis war ohnehin Blödsinn, weil
XPFILTER ja gar nicht auf die RFC-Nachricht wirkt (und der ZC-Puffer
enthält den String "?UTF-8?" gar nicht mehr).

Wäre ersteres der Fall, würde dieses Vorgehen allerdings schon das
Problem mit dem LEN-Header beheben.

>>> Mal ne dumme Frage: warum wird denn nicht im Hauptspeicher die
>>> komplette Headerzeile zusammengebaut?

>> Wird sie seit dem Enhanced UUZ doch.  Aber nicht alle Routinen, an
>> die die Headerzeile übergeben wird, sind darauf ausgelegt, sondern
>> arbeiten wie bisher mit Strings.  Das gilt insbesondere für die
>> diversen Decodierroutinen.

> Und diese ebenfalls umzustellen ist nicht möglich oder sinnvoll?

Es ist sicher möglich und vielleicht auch sinnvoll - aber es wäre zu
nicht unerheblichen Teilen ein Rewrite von XP insgesamt.

>>> [...] Oder wird die gleiche Routine auch für den Body benutzt?

>> Eben, und das hatte ich ja auch erwähnt (sonst würde ja auch das
>> Problem mit diesem Header gar nicht entstehen, siehe meine
>> Analyse).  Und speziell Jochens Fix bezieht sich eigentlich *nur*
>> auf den Body, denn das ursprünglich damit zu fixende Szenario kann
>> nur dort vorkommen.

> Ist schon ein Gewurschtel mit den 16-Bit bzw. dem arg beschränktem
> Speicherplatz unter DOS. ;)

Die Aussage oben hat eigentlich nichts mit 16bit oder dem Hauptspeicher
unter DOS zu tun.  Das von Jochen behobene Problem stellt sich
prinzipiell bei 32bit ganz genauso (ob es dort behoben wurde, kann ich
dem Code nicht entnehmen, weil ich mit den umgeschriebenen Sourcen nicht
vertraut bin, man müßte es halt mal testen).

Die Art und Weise von Jochens Fix ist allerdings 16bit-typisch, schon
richtig. Daraus entstehende Probleme - wie eben das, über das wir hier
reden - waren im Grunde vorhersehbar, wenn einem die entsprechenden
Szenarien eingefallen wären und man sie als praxisrelevant eingestuft
hätte.

Ich hätte bis zum Beweis des Gegenteils wohl auch bestritten, daß es
b64-codierte Header gibt, die in ISO-8859-* vorliegen, aber
fälschlicherweise als UTF-8 deklariert sind.

Im Grunde workarounden wir ja auch mal wieder Bugs anderer Newsreader.

> Aber grad drum ein Kompliment dafür, daß es in dem allermeisten Fällen
> sauber läuft.

Ich kenne jedenfalls aktuell keinen UUZ, bei dem es trotz noch sovieler
Bits sauberer liefe. :)

>> Da es bei Dir offenbar pressiert, kann ich Dir aber vorab mal eine
>> lauffähige Testversion zuschicken, damit Du wenigstens die Gruppen,
>> in denen dieser Poster schreibt, weiterhin beziehen kannst.  Falls
>> ich das tun soll, bitte Bescheid geben.

> Ich bitte darum. :)

Kommt heute.  Ich suche noch nach dieser ominösen Formel, von der in
RFC2279 die Rede ist und will noch die saubere Trennung zwischen
einzelnen Headern bzw. zwischen Header und Body insgesamt einbauen.

Wenn ich die Formel nicht finde, tut's die aktuelle Prüfung auf gültige
UTF-8-Sequenzen aber auf jeden Fall schon mal.


        Michael