das waer sehr schoen ja, leider kommt die regex von einer dot net applikation :( und die regex container von dot net sind leider nicht 100% perl oder pcre kompatibel... :(

wuerd mir aber einen arsch voll arbeit sparen! ;)

Der Overhead von unless(eval {qr($regex)}) ist mE. deutlich kleiner, als wenn man sich da ne n Monster-Ausdruck an regulären Ausdrücken zusammenbastelt, den du brauchen wirst, da die RE in perl recht Syntaxreich sind.

das problem bei eval - unabhängig von der performance, über die wir uns wahrscheinlich noch lange unterhalten können - ist mein Problem jetzt, dass das Modul leider nicht alle Fehler in der Regex abfängt. Soll heißen, ein { am Ende der Regex, das Perl nicht gefällt, kommt problemlos durch das Modul.

Jetzt bin ich an den Punkt, wo ich wirklich ernsthaft über die eval Geschichte nachdenke - Problem ist, dass ich dem User dann den Fehler nicht zurückgeben kann - ich kann ihm dann lediglich sagen, dass die Regex, die er übergeben hat, nicht valide ist.

Daher würde ich jetzt das Modul erweitern und für spezielle Fälle (Klammern und Varialben) Check Funktionen schreiben, die überprüfen, wieviele Klammern gesetzt wurden, wieviel davon nicht escaped sind (wieviel der escapes selber nicht escapet sind) und ob die Anzahl der Beginning Tags mit den Ending Tags passt. Somit kann ich "relativ" genau bestimmen, wo der Fehler liegt. Die letzte Instanz wäre dann ein eval Block, der prüft, ob die Regex hinhaut - wenn nicht, bekommt der User ein "undefined error" zurück.

Freue mich über kritische Kommentare ;)

jmb

Du musst zwischen String-eval und eval { } unterscheiden. Letzteres hat kein Performanceproblem und man kann Fehler sicher abfangen. Beispiel:

Allerdings sollte man trotzdem den Taint-Modus laufen lassen, wenn die Daten aus einer unsicheren Quelle kommen, und sich "perldoc re" anschauen.

ich neige mein haupt in demut.

vielen dank, das sind genau die beiden tipps, die ich gebracht habe - vielen dank

jmb