[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 #18 from Michael Matz <matz at suse dot de> ---
The types are simply incompatible:

extern int regcomp (regex_t *_Restrict_ __preg,
                    const char *_Restrict_ __pattern,
                    int __cflags);
...
extern regoff_t re_search (struct re_pattern_buffer *__buffer,
                           const char *__String, regoff_t __length,
                           regoff_t __start, regoff_t __range,
                           struct re_registers *__regs);

regex_t != struct re_pattern_buffer.  In the GNU implementation they are a
typedef
of each other (which is why there are no warnings :-/ ).  But conceptually it's
two opaque (and different) types (or rather, in POSIX a struct
re_pattern_buffer
doesn't exist).

With the pcre2 library they are _in fact_ different types, not just
conceptually. 
So regcomp (from pcre2) uses a different layout than re_search (from glibc) and
hence initializing a regex_t with regcomp (in gdb's
compiled_regex::compiled_regex() in m_pattern) but using it as a
struct re_pattern_buffer for re_search via compiled_regex::search is not going
to work.  Your work-around of putting -lc somewhere in between makes it so that
regcomp again comes from glibc (with the one in the later libpcre2 being
ignored), and hence stuff works again.  (Of course uses within libncurses that
assume pcre2 layout will be broken with the glibc regcomp).

There are multiple problems here:
1) that libpcre2 is used implicitely at all
2) If we accept (1) then it's a problem that the <regex.h> header of glibc
   is used to compile stuff, because that enables getting into the problematic
   situation to start with (with the pcre2 headers re_search would have been 
   simply undeclared, and lead to compile errors making the problem more
   obvious, or alternatively libiberty's regex.c would have been included,
   instead of relying on the mixture of glibc and pcre2)
3) Mixing re_search and regcomp on the same data would still be incorrect
   as a matter of principle, even though it happens to work when staying within
   glibc: if the design of the GNU extension would have been so that
   interoperability was intended there would have been no need for the extra
   type and initializer re_compile_pattern: regex_t and regcomp would suffice.
4) But, as something like re_free is missing the design of the GNU extension
   also isn't completely orthogonal to POSIX regex_t, leading to necessary
   mixture which is actually incorrect as per (3).

(3) and (4) together make it so that the GNU extension involving
struct re_pattern_buffer can only be used in very controlled circumstances,
and (1) breaks those circumstances :-/

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