Re: what does regex depend on sys_wait?

[Jim Meyering]

Bruno Haible wrote:

> Eric Blake wrote:
>> Because POSIX requires <stdlib.h> to provide WEXITSTATUS, among others,
>> but some systems don't do this by default.  Therefore, the stdlib module
>> depends on sys_wait.
>
> This explains why 'stdlib' depends on 'sys_wait'.
>
> And why does 'regex' depend on 'stdlib'? 'regex' does not encounter any of the
> portability problems that are listed in
> <http://www.gnu.org/software/gnulib/manual/html_node/stdlib_002eh.html>.
> But there is a dependency chain
>   regex --> malloc-gnu --> malloc-posix --> stdlib
> In other words, the regex code assumes a glibc compatible malloc, and
> this rpl_malloc() replacement needs to be defined in gnulib's substitute
> for <stdlib.h>.
>
> gnulib does not, among the modules that it provides, make a distinction
> between "stdlib.h which just defines malloc" and "stdlib.h which is
> completely POSIX". Providing more fine-grained modules would increase
> the size the meta-information even more. For my feeling, the size of
> the meta-information (module descriptions) is already larger than most
> people like it to be.
>
> So, in order to cut this dependency, it would be necessary to change
> regcomp.c and regexec.c so that its malloc calls
>   1. protect the argument so it is never 0,
>   2. set errno = ENOMEM in case of failure.
> Since this is redundant on glibc platforms, Jim has been opposed to this
> change (as far as I recall).

Hi Bruno,

If the regex code in gnulib were the primary source and/or
glibc were easier to update, a strategic change might be ok.
However, I don't like the idea of gnulib carrying even more
regex changes relative to glibc sources because that makes
the already tedious merge/sync process that little bit riskier.

Given the number of matches I see here (95 lines):

    git grep -w -E '(re_)?(re|m|c)alloc' lib/reg*.[ch]

I would not want to embark on this task, and even less to have
to wade through the additional differences the next time
we try to sync glibc and gnulib.

However, if someone can come up with a patch that is relatively
noninvasive, maybe...  It's hard to say without seeing just how
big a change would be required.