This is the mail archive of the libc-alpha@sourceware.cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: regncomp/regnexec for glibc ?


In <m33drqsapj.fsf@localhost.localnet> Ulrich Drepper (drepper@cygnus.com) wrote:
UD> "Khimenko Victor" <khim@sch57.msk.ru> writes:

>> Is it possible to add such functions in glibc ? With following prototypes:

UD> I will not add anything to regex.  It's fragile enough.  Any
UD> additional interface will hve to wait for a rewrite.

I do not ask to change anything in RegEx internals. regex_compile and re_search
works just fine. re_search can be used easily (it's not internal - it's exposed
in /usr/include/regex.h) while regex_compile can not be accessed from outside.
There are ALREADY exist interface to call regex_compile with embedded NULL's
via re_compile_pattern but regex_compile_pattern uses global variable
re_syntax_options - not good for threads :-(

UD> Ad beside: C does not allow NUL bytes in strings, so fix the callers.

C allows NUL bytes in strings (it's even used in regex.c if I recall correctly).
Like this: "it\'s\0embedded\0NULL"... Just so happens that some library
functions can not cope with this. RegEx works with them (at least sometimes :-)
Just there are no interface to call it :-(

UD> These are C interfaces.

Unfortunatelly glibc is not "just basic C library". For better or for worse
it's basic system library on Linux and all other languages are using it.
And there are no interface in regex suitable for other languages where NUL
bytes in strings are not second-grade citizens (like Pascal or PHP).

P.S. About regex rewrite: is it planned some time soon or there are will be
no changes in regex allowed for next 10 years ?




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]