История изменений

Иными словами, ТС прав, когда с самого начала утверждал "стандартные POSIX регексы из glibc работают на порядок медленнее чем в … ". Проблема - определение интерфейса regexec, которое так сделано из-за ограничений С. Так?

Как тебе сказать… ТС нашёл пример, когда программа на Си работает значительно медленнее аналогичной программы на Луа. Пример конкретный — очень длинная строка, в которой много-много-много раз ищется вхождение, соответствующее регулярному выражению. Но вот формулировка проблемы ТСом («стандартные POSIX регексы из glibc работают на порядок медленнее чем в Lua») опускает множество деталей, и получается слишком сильное обобщение.

Прав ли ТС? В общем случае нет: можно составить другой пример, когда из массива с несколькими миллионами коротких строк будут выбираться строки, соответствующие регулярному выражению. Будут ли в этом примере «стандартные POSIX регексы из glibc на порядок медленнее»? (Особенно если склеивать соответствующие строки в одну большую…)

Вторая половина твоей формулировки «определение интерфейса regexec, которое так сделано из-за ограничений С» тоже не вполне точна. Строго говоря, обсуждаемая проблема возникла не из-за сишных ограничений, а из-за сишных э-э-э… традиций, что ли. Ничто не мешает реализовать на Си другой интерфейс, например:

int regexec(const regex_t * preg, const char * string, size_t len,
    size_t nmatch, regmatch_t pmatch, int eflags);

(обрати внимание на параметр len), и проблемы не будет. Собственно, в плюсовой библиотеке так и сделали. Почему разработчики POSIX стандарта не сделали это сразу — хз. Видимо, не рассчитывали на такой случай, как у ТС.

P. S. Возможно, есть ещё один вариант: переписать regexec так, чтобы длина строки ему была не нужна, но в эту область я лезть не хочу.

Иными словами, ТС прав, когда с самого начала утверждал "стандартные POSIX регексы из glibc работают на порядок медленнее чем в … ". Проблема - определение интерфейса regexec, которое так сделано из-за ограничений С. Так?

Как тебе сказать… ТС нашёл пример, когда программа на Си работает значительно медленнее аналогичной программы на Луа. Пример конкретный — очень длинная строка, в которой много-много-много раз ищется вхождение, соответствующее регулярному выражению. Но вот формулировка проблемы ТСом («стандартные POSIX регексы из glibc работают на порядок медленнее чем в Lua») опускает множество деталей, и получается слишком сильное обобщение.

Прав ли ТС? В общем случае нет: можно составить другой пример, когда из массива с несколькими миллионами коротких строк будут выбираться строки, соответствующие регулярному выражению. Будут ли в этом примере «стандартные POSIX регексы из glibc на порядок медленнее»? (Особенно если склеивать соответствующие строки в одну большую…)

Вторая половина твоей формулировки «определение интерфейса regexec, которое так сделано из-за ограничений С» тоже не вполне точна. Строго говоря, обсуждаемая проблема возникла не из-за сишных ограничений, а из-за сишных э-э-э… традиций, что ли. Ничто не мешает реализовать на Си другой интерфейс, например:

int regexec(const regex_t * preg, const char * string, size_t len,
    size_t nmatch, regmatch_t pmatch, int eflags);

(обрати внимание на параметр len), и проблемы не будет. Собственно, в плюсовой библиотеке так и сделали. Почему разработчики POSIX стандарта не сделали это сразу — хз. Видимо, не рассчитывали на такой случай, как у ТС.