Laut dieser Vorgabe (RFC 1522) dürfen in E-Mail-Headern nur die ersten 127 Zeichen des ASCII-Zeichensatzes benutzt werden. Quasi nur alphanumerische Zeichen und eine Hand voll Sonderzeichen. Also auf keinen Fall Umlaute oder ähnliches.

Wenn man zum Versenden z.B. das Perl-CPAN-Modul MIME::Lite benutzt, werden die nicht erlaubten Zeichen nicht automatisch konvertiert. Da muss man sich selber kümmern.

Am leichtesten geht es mit dem Perl-CPAN-Modul MIME::EncWords. Die Funktion MIME::EncWords::encode_mimewords(STRING) : QUOTED_STRING macht eben genau diese Konvertierung, wobei es interessanter weise den aktuellen Zeichensatz erraten kann. Diesen Teil werde ich noch mal genauer unter die Lupe nehmen, da es schon länger auf meiner Liste steht.

Wie oben schon erwähnt, kann und sollte man alle E-Mail-Header quoten. Die Funktion ändert im übrigen den übergebenen String nur, wenn es wirklich nötig ist. Reine Ascii-Inhalte, die unterhalb der 127 Zeichens liegen, werden so belassen wie sie sind. Den E-Mail-Inhalt sollte man aber nicht damit übersetzen lassen. Das funktioniert zwar auch soweit, aber die Zeilenumbrüche sind bei mir dabei verloren gegangen.

use Test::More tests => 1;
{
package Foo;
sub new {
bless([])
}
sub DESTROY {
eval {
die('destroy');
}
}
sub bar {
die('bar');
}
}
eval {
my $foo = Foo->new();
$foo->bar();
};
main::diag($@);

in $@ sollte eigentlich sowas wie bar at Test.pm line x erscheinen, aber er ergibt destroy at…. Was ist also passiert? Es ist, wie in der “Fehlerbeschreibung” erwähnt eigentlich kein Fehler, sondern eine Nebenwirkung davon, dass in Perl fast alles mit globalen Variablen gelöst wird. Wenn man den Code ein wenig erweitert, sieht man deutlich, was passiert:

#!perl -T
use Test::More tests => 1;
{
package Foo;
sub new {
main::diag('new() called');
bless([])
}
sub DESTROY {
main::diag('DESTROY() called');
eval {
die('destroy');
}
}
sub bar {
main::diag('bar() called');
die('bar');
}
}
main::diag('eval-START');
eval {
my $foo = Foo->new();
$foo->bar();
}; # HERE!
main::diag('eval-END');
like($@, qr/^destroy/, 'croak in DESTROY()');

Folgende Ausgabe wird erzeugt:
# eval-START
# new() called
# bar() called
# DESTROY() called
# eval-END
Zwischen dem Aufruf von bar() und eval-end mogelt sich das DESTROY frech dazwischen. Es gibt hier eine Nebenläufigkeit, da $foo am Ende des Eval-Blockes nicht mehr existiert und der GarbadgeCollector artig DESTROY() auf das Objekt aufruft. Da es aber nur eine Kopie von $@ gibt, wird der Inhalt durch das DESTROY-eval{} einfach überschrieben, denn das soll eval{} bei jedem Aufruf ja auch tun.

In der “Fehlerbeschreibung” ist als mögliche Lösung angegeben, man soll immer local verwenden, um z.B. $@ nicht zu überschreiben. Um auf “Hat Fehler” zu prüfen würde ich lieber ein
my $ok = eval {
#...some code
return 1;
};
verwenden, da man da erst gar nicht auf $@ angewiesen ist. Der Inhalt von $@ wird damit aber immer noch überschrieben werden.

Dieses Verhalten hat mir mal wieder gezeigt, dass mit allen Spezialmethoden von Perl, also import(), BEGIN, CHECK, END, INIT, DESTROY() und alle anderen, die zu bestimmten Ereignissen aufgerufen werden, immer sehr umsichtig umgegagnen werden muss. Am besten viele Diagnosemeldungen ausgeben lassen, damit man nicht den Überblick verliert.

Ich hab gerade ein paar Minuten damit zugebracht, ein Modul zu aktualisieren und hatte mich gewundert, warum meine Änderungen keine Wirkung hatten.

sub existing_sub;
sub defined sub { die 1; }
print __PACKAGE__->can('notexisting_sub'); #false
print exists(&notexisting_sub); # false
print defined(&notexisting_sub); # false
print __PACKAGE__->can('existing_sub'); #true
print exists(&existing_sub); # true
print defined(&existing_sub); # false
print __PACKAGE__->can('defined_sub'); #true
print exists(&defined_sub); # true
print defined(&defined_sub); # true

Der Aufruf einer Methode, die nur deklariert, führt zu einem “Undefined subroutine .. called” fehler, den man ja eigentlich mit dem can() verhindern wollte. Mir ist noch nie eine solche, blanke Deklaration über den Weg gelaufen, aber man weiß ja nie.

Einiges kommt, zumindest mir, bekannt vor. Speghetti-Code, Gott-Objekt und die Spinnen sehr ich schon sehr oft. Höchste Zeit, das zu ändern.

In den bemängelten Zeilen steht lediglich use base ‘KLASSENNAME’;. Heißt das jetzt, dass “base” unsicher ist? Ja, es ist mit dem bösen “fields” fest verdrahtet, aber was genau soll jetzt hier falsch sein?

Es ist vor allem merkwürdig, dass die Tests auf 50 Systemen problemlos durchgelaufen sind und dieses eine Meckert.

Die Variable $overfloating_float_string ist eigentlich nicht korrekt erzeugt worden aber das ist hier gar nicht das Problem. Bei den meisten Testsystemen für Fukurama::Class ging alles gut, bis auf bei diesen dreien:

i686-linux-thread-multi-64int-ld2.6.21.5-smp
i686-linux-thread-multi-64int-ld2.6.21.5-smp
x86_64-linux-thread-multi-ld 2.6.22.10

Dort ergab sich ein die Fehlerhafte Ausgabe: Overfloat at: 9.99999999999999997e+4931 Ich weiß ja, dass es bei Fließkommaberechnungen Ungenauigkeiten gibt, aber die Art war mir neu.

Insgesamt sind derzeit 115 Fehler gemeldet, einige davon schon seit Jahren. Live erlebt habe ich den folgenden Fehler in der url() Methode. Ungequotet wird der Scriptname in eien Regex gesetzt. Unter mod_perl ist dummerweise der Scriptname der gesamte Pfad. Ein [ im Pfad der URL führt zu einem Laufzeitfehler, wenn man diese Funktion in der Anwendung benutzt.

Ende vom Lied: ich werde mich wohl mal nach einer Alternative umsehen, die sich AUSSCHLIEßLICH um die Entgegenname von Parametern kümmert und noch ein zweites für die Ausgabe von HTTP-Headern.

Mein konkretes Beispiel: das Modul HTML::Tidy, was auch in anderen Modulen öfter verwendet wird, ist ein wenig Bug-verseucht. Das ist mir leider erst NACH dem Produktiveinsatz aufgefallen. Das Encoding wird von ISO nach UTF oder anders herum durchgeführt, ohne dass man das mitgeteilt bekommt. Am Ende hatte ich hunderte schadhafte Datenbankeintragungen

Fazit: wenn man ein CPAN-Modul benutzen will, sollte man die Bugs, die Anzahl der durchgefallenen Tests, die Bewertung und den Quellcode ganz genau betrachten. Dumm ist nur, dass einige Module so viele Abhängigkeiten haben. Da ist eine komplette Prüfung ‘ne ziemliche Sysiphos-Arbeit. Aber man sonnte sich die Arbeit machen. Immer!

1. Zahlenüberläufe werden unterschiedlich markiert. Ich kenne inf, Solaris z.B. benutzt aber Infinity und einige andere hatten noch ein Inf am Start (großgeschrieben). Das fällt nie auf, auer man behandelt genau diese Überläufe.

2. Klassennamen können nicht immer als Parameter übergeben werden. Ich hatte im Test ein $obj->param(My::Class) verwendet. Das schlug aber komplett fehl. Ich musste es als String übergeben ala $obj->param(‘My::Class’). Nicht weiter tragisch, sofern man es denn weiß. PS: Für __PACKAGE__ gilt das natürlich auch.

Soeben ist ein CPAN-Tester mit einer Windows-Gurke über meine Tests gelaufen. Ich weiß, daß in Visual-Basic z.B. die Boolische Werte in der Landessprache geschrieben werden können. Wie z.B. “true”, “wahr” oder “vrai”. Bei Perl haben sie sich auch Mühe gegeben: -1.#IND für NaN und 1.#INF für Inf. Toll!

In dem Modul erzwinge ich jetzt einen Überlauf und suche mir halt die Systemeigenen Werte. Hmpfrl!