TPerlRegEx - stack overflow

[ele]

Zitat von WladiD:

Zitat von ele:

Folgende RegEx funktioniert:

Code:

({4:\r\n(?:[^\r\n]*\r\n)*?-})

Ich habe keine Ahnung von SWIFT (zumindest nicht im Detail), aber der reguläre Ausdruck ist definitv nicht richtig.

- Geschweifte Klammern haben in pcre eine spezielle Bedeutung (Quantifizierung) und müssen daher escaped werden, wenn man sie matchen möchte
- Das Fragezeichen vor der Klammer ist auch fragwürdig, denn es ist ein Quantifizierer also ein Kürzel für {0,1} und ein vorhergehendes Char, Set oder Gruppe fehlt demnach

Du hast recht, es ist besser die geschweiften Klammern zu escapen. Trotzdem ist es eine absolut gültige RegEx:

Zitat von http://perldoc.perl.org/perlre.html:

If a curly bracket occurs in any other context and does not form part of a backslashed sequence like \x{...} , it is treated as a regular character.

Zur aktuellen Diskussion:
Das debuggen von PCRE willst du dir nicht antun - selbst wenn der code in Delphi geschreiben wäre. Regular Expression Engines sind ein ziemlich komplizierte Dinger und die PCRE ist ein Monster. Da schreibst du lieber deinen eigenen Parser - das benötigt weniger Zeit.

[WladiD]

Zitat von ele:

Du hast recht, es ist besser die geschweiften Klammern zu escapen. Trotzdem ist es eine absolut gültige RegEx:

Zitat von http://perldoc.perl.org/perlre.html:

If a curly bracket occurs in any other context and does not form part of a backslashed sequence like \x{...} , it is treated as a regular character.

Ja, du hast Recht, das habe ich im Nachhinein auch erfahren. Ich persönlich escape generell alle Zeichen, die irgendeine anderweitige Bedeutung im Ausdruck haben, so ist man auf der sicheren Seite. Vor allem wenn man den Punkt an sich matchen möchte, sollte man ihn tunlichst nicht vergessen zu escapen

Zitat von ele:

Zur aktuellen Diskussion:
Das debuggen von PCRE willst du dir nicht antun - selbst wenn der code in Delphi geschreiben wäre. Regular Expression Engines sind ein ziemlich komplizierte Dinger und die PCRE ist ein Monster. Da schreibst du lieber deinen eigenen Parser - das benötigt weniger Zeit.

Keine Software ist perfekt, aber die PCRE halte ich für eines der solidesten Projekte, die die IT-Branche zu bieten hat. Sodass man zuerst an der eigenen Expression zweifeln sollte, bevor man einen Bug in der PCRE vermutet.

[liftoff]

Also einen Bug habe ich auch nie vermutet.

Eingangs wollte ich nur die Stackbehandlung in pcre allgemein und an diesem Punkt jetzt die unterschiedliche Stackbehandlung von greedy- und nongreedy Ausdrücken ein wenig besser verstehen. Wenn nongreedy sich bei gleichem Matchergebnis ressourcenschonender verhält, wäre das ja auch mal eine wichtige Erkenntnis.