Re: [libiberty] does anyone use regex.c with REGEX_MALLOC?

[Aldy Hernandez <aldyh at redhat dot com>]

On 07/25/2016 06:30 PM, Manuel López-Ibáñez wrote:
> On 25/07/16 21:16, Joseph Myers wrote:
> > On Mon, 25 Jul 2016, Jeff Law wrote:
> >
> > > I'll pre-approve removing those bits.  Alternately, you could look to
> > > resync
> > > with glibc, though that could prove painful after 15 years of
> > > divergence.
> >
> > The current glibc implementation is completely different; the libiberty
> > version was replaced in glibc many years ago.  Obsolete libiberty by
> > gnulib for all its users and you get a portable version of the current
> > glibc regex that way....
>
> BTW, this is what Ayush is trying to do:
>
> https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01302.html
>
> https://gcc.gnu.org/wiki/replacelibibertywithgnulib
>
> It would be great if someone could review his patches. I cannot approve
> them myself.
>
> You could even ask him to look next at replacing the libiberty version
> of regex.c with gnulib's in GCC. It is on his TODO list.

Well, if libiberty is going to be replaced en masse by gnulib, then 
there's no sense in me cleaning up libiberty's regex.

Out of curiosity I tested gnulib's regex implementation by building 
glibc (since it seems to be the same code) with my -Walloca patch 
(-Walloca-larger-than=4096).  Cursory tests show that libc's regex*.c 
are in much better shape with regards to unbounded allocas.  Actually, I 
only see one real problem and one possible false positive.

For the curious, the possible unbounded alloca is in gnulib's regcomp.c:

	  if ((bufp->syntax & RE_ICASE) && dfa->mb_cur_max > 1)
	    {
	      unsigned char *buf = alloca (dfa->mb_cur_max), *p;

Before I spend any more time on this, is there a plan to review Ayush's 
work for say GCC 7?  I obviously only care about regex* right now, or 
any alloca users in libiberty :).

Aldy