Re: [PATCH][gdb/build] Hardcode --with-included-regex

[Tom Tromey <tom@tromey.com>]

>>>>> "Tom" == Tom de Vries <tdevries@suse.de> writes:

Tom> A note on the latter: it's actually a bug to compile a regex using regcomp and
Tom> then pass it to re_search.  The GNU regex interface requires one to use
Tom> re_compile_pattern or re_compile_fastmap.  But as long we're using one of the
Tom> GNU regex incarnations in gnulib, glibc or libiberty, we get away with this.

Tom> The PR could be fixed by adding -lc in a specific position in the link line,
Tom> to force regcomp to be bound to glibc.  But this solution was considered
Tom> in the discussion in the PR as being brittle, and possibly causing problems
Tom> elsewhere.

Tom> Another solution offered was to restrict regex usage to posix, and no longer
Tom> use the GNU regex API.  This however could mean having to reproduce some of
Tom> that functionality locally, which would mean maintaining the same
Tom> functionality in more than one place.

Just to be clear, using the GNU extensions isn't currently done, I
think.  I'd like to use them so GDB can avoid copying some strings to
ensure they are \0-terminated; but this isn't done at the moment.

So, it would also be equivalent, right now, to switch GDB to conform to
POSIX here.

Personally I'm fine with just requiring the libiberty regexp.
That said we should probably see if there are differing opinions, or
some reason to keep the flag.

thanks,
Tom