дядя, вы чего-то не того накрутили... может это конечно следствие gnuregex,
но в остальбном мире юзают regex(3), где regcomp, regexec и прочее...
и нету никаких re_compile_pattern, re_match и прочего безобразия...
так что это все не очень переносимо как бы...
Но, я бы воздержался от
#ifndef MIN
#define MIN(x,y) ((x < y) ? x : y)
#endif
потенциальные грабли это, если вместо x будет стоять функция.
А в этом случае
#define safe_free(p) { if (p) { free(p); p = NULL; } }
Линуксойдам советуют использовать do{ }while(0) вместо внешних скобок {}
Честно говоря, особого смысла использовать re_compile_pattern я не вижу.
Что re_compile_pattern(), что regcomp() вызывают re_compile_internal() (судя по исходникам glibc 2.3.2), но при этом по regcomp(), regexec() есть вполне внятное info.
> Если внимательно посмотреть то так оно и есть.
вот и посмотрите внимательно, что это нихрена не будет работать
на BSD системах.
> Проект писался для возможной сборки и с regex и с gnuregex
:)
> Вобщето проект создавался под фрёй и лет 5 под ней уже проработал.
я говорил про OpenBSD, но сейчас и во фре гляну...
будет странно если там не так...
> будет странно если там не так...
ну дык... смотрю на 4.9:
- есть gnuregex.h и там есть все эти re_compile_* и прочее.
- есть regex.h в котором этого НЕТ.
так вот получпается, что на Фре у Вас HAVE_GNUREGEX_H
определено и он смотрит в gnuregex.h, а не в regex.h.
отсюда вывод: ЭТОТ КОД НЕПОРТАБЕЛЕН.
в том же Solaris этого может и не быть, как его нет в OpenBSD.
> отсюда вывод: ЭТОТ КОД НЕПОРТАБЕЛЕН.
С точки зрения POSIX (sorry не дописал)...
Хотя на POSIX сейчас частенько кладут, в данном случае, imho,
не надо так делать. Тем более, что есть устоявшийся интерфейс
описаный в regex(3).