tobo hat geschrieben:
Von wann ist POSIX-ERE, 1986?
Das Zitat ist aus ``The Open Group Base Specifications Issue 7, IEEE Std 1003.1, 2013 Edition''.
POSIX kann umgesetzt sein, muss aber nicht. Kann erweitert sein, muss aber nicht. Wenn ich ein konkretes Problem habe, dann interessiert mich nicht der möglicherweise nicht erweiterte umzusetzende Standard, sondern die exakte Implementierung. Und insbesondere die Dokumentation dieser Implementierung!
Dem stimme ich zu. POSIX *kann* umgesetzt sein, muss aber nicht. Mich interessiert auch wie es tatsaechlich implementiert ist, aber der Aufwand das im Code herauszufinden ist viel zu gross, also schaue ich in die Dokumentation. Meiner Erfahrung nach ist POSIX eine sehr hilfreiche Dokumentation, die einen Detailgrad bietet, den fast keine Programmdoku hat und an der sich typischerweise die Entwickler solcher Software orientieren. Natuerlich ist mir bewusst, dass nicht jede Umsetzung standardkonform ist, aber fuer mich war der Ansatz in POSIX zu schauen meist hilfreich (gerade eben auch in Ermangelung von guter anderer Doku).
(Leider ist gnu.org schon den ganzen Tag down, so dass ich dort nicht nach bassender Doku suchen konnte.)
Any of the following uses produce undefined results:
If these characters appear first in an ERE, or immediately following a <vertical-line> [...]
Bedeutet lediglich, dass es in der Vorgabe undefiniert ist. Das hat für die Implementierung genau gar nichts zu sagen.
Genau. Aber ist schon mal eine wertvolle Information.
Genau genommen würde ich als Programmierer jedes undefinierte Verhalten erstmal abschaffen wollen. Das ist ja nichts anderes, als ein fehlender Case-Fall in der Umsetzung!? Sprich, ein Programmierfehler.
Ich denke, da hast du die Bedeutung des Wortes ``undefiniert'' im Standard falsch verstanden. Es bedeutet nicht, dass die jeweilige Implementierung hier segfaultet oder explodiert. Etwas das in einem Standard undefiniert ist, bedeutet, dass sich das Verhalten je nach Implementierung unterscheiden kann. Es kann (und wird vermutlich) durchaus definiert sein, was GNU egrep in dem Fall macht, aber z.B. FreeBSD egrep wird vielleicht etwas anderes machen.
(Ich fuer meinen Teil will ungerne Verhalten nutzen, das in POSIX undefiniert ist, weil das zwar oft mit den GNU Tools funktioniert aber auf anderen Unixen nicht tut.)
Wenn ich irgendwas in ein Programm eingebe und das Teil fliegt mir dann möglicherweise um die Ohren, dann ist das kein undefiniertes Verhalten, sondern ein Programmierfehler. Und genau deswegen hat hier GNU (und da gebe ich dir Brief und Siegel, und zwar ohne das zu wissen) ein definiertes Verhalten eingeführt.
Klar, definiert von GNU fuer seine eigene egrep-Implementierung, aber undefiniert in POSIX und damit moeglicherweise uneinheitlich ueber alle egrep-Implementierungen die es so gibt. (Relevant fuer alle die, die ab und an ueber den Horizont der GNU/Linux-Welt hinausschauen.)
Da GNU und Dokumentation sich aber oft wie gleiche Magnetpole verhalten, muss man das vermutlich wirklich im Quelltext nachschauen, damit man Sicherheit erlangt!?
Wie meinst du das mit den Magnetpolen? Das habe ich nicht verstanden.
Natuerlich erlangt man Sicherheit nur wenn man in den Code schaut, aber ich weiss nicht ob du dir bewusst bist wie eine Regexp-Engine im Code so aussieht, und von den theoretischen Grundlagen ganz zu schweigen. Viel Vergnuegen beim Einarbeiten! Wird vermutlich mehrere Monate dauern.
Edit: Aber vielleicht ist's ja auch gar nicht so schlimm. Ich lasse mich sehr gerne widerlegen!
