Re: new module 'regex-quote'

[Bruno Haible]

Hi Reuben,

> > But the fact is that POSIX standardizes the regex API, and therefore there
> > is a border between "in glibc" and "outside glibc". Functionality in glibc
> > is available at no cost; functionality outside glibc requires additional
> > link options and increased startup time or a 50KB bigger executable.
> 
> Equally, libc APIs such as the crappy standard string handling
> functions waste my time on a daily basis, whereas APIs from other
> libraries save it. ... libc's general weakness in so many areas
> means I consider third-party libraries much more often than in other
> languages.

Yes, I agree that the POSIX libc APIs are loaded with historical baggage
and unorthogonal etc. gnulib and many other projects try to create more
consistent and more convenient APIs.

> My suggestions
> aim at a situation in which, in a few years, the situation is much the
> same but the application code is cleaner (and there are not lots of
> statically-linked "quote_regexp" functions). And then, a few years
> later, the changes get into glibc and the statically linked copies
> disappear.

It is a nice dream, but you have to know that the way for some feature
into glibc is hard. Either you have to convince Ulrich Drepper, or you
have to convince the Austin group. Making a fork in some GNU project,
such as gnulib, is _not_ sufficient.

My point about the border between "in glibc" and "outside glibc" is
two-fold:
  - Consistency of API: If you want to make an API that some day gets
    into glibc, you need it to be as close as possible to the POSIX
    API. If not, you are free to design a better one.
  - Deployment: If you want something to be inside glibc one day,
    you need to put it into a library that will become obsolete on
    those platforms with the newer glibc. Like libintl and libiconv.
    If you put something into a library like libglib or libxml or
    libunistring, it will never be inside glibc.

> (I am also rather alarmed at the way that gnulib seems to be growing
> without bound; it should be making bits of itself redundant just as
> fast as it can, so that it's the glue between the near past and the
> near future, not just another big ball of wax that keeps accreting.)

I don't find this alarming:
  - The POSIX emulation part of gnulib is growing because we support more
    and more POSIX functions. _Exit and tcgetsid are the newest ones.
  - The convenience part of gnulib is growing because gnulib is adopted
    by more projects, and more people contribute to it. Latest additions:
    'astrxfrm' and 'host-cpu-c-abi'. Do you see anything wrong with these?

Bruno