Re: regncomp/regnexec for glibc ?

["Khimenko Victor" <khim at sch57 dot msk dot ru>]

In <Pine.LNX.4.10.10001220903300.832-100000@ashi.FootPrints.net> Kaz Kylheku (kaz@ashi.footprints.net) wrote:
KK> On Sat, 22 Jan 2000, Khimenko Victor wrote:

>> 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).

KK> C allows one nul byte in a string: the one at the end.

AFAIK in C itself the only operation with strings is it's definition. All
other things are in system library.

KK> I think what you mean is that C allows null bytes in character arrays. A
KK> character array is not a string.  A C string object is a character array with
KK> one null byte in the last position.  This representation is supported by the
KK> standard C library, as well as many other interfaces, not to mention the
KK> language itself, whose semantics automatically add an implicit null byte at the
KK> end of string literal objects.

In language itself it's the only place where string conception is used.

>> 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.

KK> Regex functions are not system functions. They are purely algorithmic.  There
KK> is no operating system feature that you cannot access for lack of being able to
KK> use these functions.

The same is true for iconv, for example. And for other things. Of course all
such "purely algorithmic" things can be duplicated in Pascal library, in Ada
library and so on. I do not think that we need all this stuff in libraries for
all languages. We need bindings for different languages and ONLY when it's not
possible without deep rework of underlaying c library work should be dumplecated
(triplicated, etc). IMHO, of course.

KK> The regex functions are in libc because POSIX defines them and lots of POSIX
KK> applications won't work if you don't have them.

But if it's in basic system library already then why we need other regex
implementation in system ?

KK> When the POSIX guys decide to invent regex bindings for Pascal, then portable a
KK> library can be written for Pascal programs which supports these bindings.

There are quite a few things in glibc (gcc, and other GNU utilities) not
mandated by POSIX. There are languages not even mentioned in POSIX (like PHP).
And I'm not sure if POSIX says anything about sheme implementation is system
and other such things.

KK> There are POSIX bindings for languages other than C, notably Ada.  Note
KK> that the Ada bindings do not simply mimic the C interface function by function,
KK> but are mapped to the language characteristics in some sensible way. For
KK> instance, you don't get FILE * streams or the malloc function.

Of course. The same is true for regex binding in GPC: it does not mimic C
library interface. But when you need to do "real work" it calls functions
regncomp and regnexec from librx (or something like that). So you must
download separate library and install it. Since the same thing is avalable
from glibc it looks little riduculosly...