Анатолий, у вас опечатка — ссылка на DeadJournal ведет на ЖЖ. Воистину добро побеждает зло :)

Ой :)
Спасибо, исправил.

Анатолий, а вдруг это не баг? :-)

Поглядите вот сюда, плз: http://bugs.php.net/?id=20698

Я детально не смотрел суть бага в перле, но он показался мне похожим на найденный мной "баг" в php.

Суть в том, что если matches слишком много, то PCRE падает. Но виновата не PCRE (хотя могла бы и не падать), а те, кто пишут регекспы, которые матчат слишком много матчей, грубо говоря.

Интерпретатор языка не должен падать в любом случае. Это как бы аксиома :) если регексп слишком тяжёлый, PCRE должна вернуть ошибку, а не переполнить стэк; а если переполняет, то это баг. Так мне кажется.

Ответ PHP-шных девелоперов на Ваш баг мне кажется, откровенно говоря, глупым.

Я сейчас копаюсь в недрах перловской библиотеки регекспов, и там есть поддержка избежания бесконечной рекурсии и прочих подобных прелестей, но почему-то она не срабатывает.

Не то чтобы очень глупым, PCRE-то не они пишут. Но по сути ты прав, конечно.

О результатах расскажешь?

Следи за ссылкой на Зиллу, я уже туда заслал немного результатов. Скоро ещё будет.

Что касается твоего конкретного случая с PHP и PCRE: попробуй вместо (\n|?) использовать
(?:\n|?) и скажи мне, предотвращает ли это крэш :)

Вернее,
(?:\n|.)* вместо (\n|.)* .

Интересно, спасибо. Но я не убеждён. Столь простой regexp, как в том примере, в Перле не приводит к крэшу; более того, небольшое варьирование перловского regexp'а приводит к нормальной работе. Так что я подозреваю, что может быть баг в компиляторе regexp'ов.