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 ?


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

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

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

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

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

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

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

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


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