[Bug gdb/27681] FAIL: gdb.base/help.exp: apropos \(print[^[ bsiedf\".-]\) (timeout)

["matz at suse dot de" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=27681

--- Comment #23 from Michael Matz <matz at suse dot de> ---
(In reply to Tom de Vries from comment #22)
> I wonder if libiberty has the same problem.
> 
> I'm currently building with --with-included-regex and gdb seems to work
> fine, and it eliminates any dependencies on external regex providers.
> 
> But libiberty has the same difference in declared types:
> ...
> int
> regcomp (regex_t *preg, const char *pattern, int cflags)
> ...
> and:
> ...
> int
> re_search (struct re_pattern_buffer *bufp, const char *string, int size,
>            int startpos, int range, struct re_registers *regs)
> ...
> 
> So, are these two compatible in libiberty or not?

_Within_ libiberty (which is essentially the same a gnulib/regex*.c and
glibc/regex*.c) these are compatible types, and using regcomp with re_search
works.  As soon as you replace the POSIX ones (and only those) with different
implementations the same problems occur.  Which is why mixing re_search and
regcomp is basically a problem in waiting when you can't ensure that both come
from the same implementation.  (Linking statically against libiberty or gnulib
would ensure this, as would directly linking in regex.o, but linking
dynamically
against libc and pcre2-posix would not).

-- 
You are receiving this mail because:
You are on the CC list for the bug.