From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 837FC3893676; Tue, 6 Apr 2021 15:51:13 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 837FC3893676 From: "matz at suse dot de" To: gdb-prs@sourceware.org Subject: [Bug gdb/27681] FAIL: gdb.base/help.exp: apropos \(print[^[ bsiedf\".-]\) (timeout) Date: Tue, 06 Apr 2021 15:51:13 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: gdb X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: matz at suse dot de X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gdb-prs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-prs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2021 15:51:13 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D27681 --- Comment #18 from Michael Matz --- 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 !=3D 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.=20 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 go= ing 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 t= hat 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 header of glibc is used to compile stuff, because that enables getting into the problema= tic situation to start with (with the pcre2 headers re_search would have bee= n=20 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 wi= thin 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 suffi= ce. 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 :-/ --=20 You are receiving this mail because: You are on the CC list for the bug.=