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
