On Mon, Apr 14, 2025 at 02:47:06PM -0700, Paul Eggert wrote:
> +++ b/doc/posix-headers/regex.texi
> @@ -11,6 +11,19 @@ regex.h
> @item
> This header file is missing on some platforms:
> mingw, MSVC 14.
> +
> +@item
> +On some systems that have this header file,
> +GNU extensions like @code{re_set_syntax} and @code{RE_SYNTAX_EMACS}
> +are not declared or supported:
> +FreeBSD 14.2, OpenBSD 7.6, NetBSD 10.1, macOS 15,
> +Minix 3.3.0, AIX 7.3, HP-UX 11, Solaris 11.4.
> +
> +@item
> +On some systems that support GNU extensions, @code{RE_SYNTAX_EMACS} is 0
> +even though it should be @code{(RE_CHAR_CLASSES | RE_INTERVALS)}
> +to be compatible with Emacs 21 (2001) and later:
> +glibc 2.41, Cygwin 2.6.x.
> @end itemize
>
> Portability problems not fixed by Gnulib:
Should the paragraph on RE_SYNTAX_EMACS being 0 on some platforms be
listed in the section of portability problems NOT fixed by Gnulib,
since we are now intentionally NOT overriding glibc merely because of
that difference?
> +++ b/m4/regex.m4
> @@ -1,5 +1,5 @@
> # regex.m4
> -# serial 80
> +# serial 81
> dnl Copyright (C) 1996-2001, 2003-2025 Free Software Foundation, Inc.
> dnl This file is free software; the Free Software Foundation
> dnl gives unlimited permission to copy and/or distribute it,
> @@ -54,9 +54,10 @@ AC_DEFUN([gl_REGEX]
> static void sigabrt_no_core (int sig) { raise (SIGTERM); }
> #endif
>
> - #if !RE_SYNTAX_EMACS
> - # error "RE_SYNTAX_EMACS does not match Emacs behavior"
> - #endif
> + /* There is no need to check whether RE_SYNTAX_EMACS is
> + (RE_CHAR_CLASSES | RE_INTERVALS), corresponding to
> + Emacs 21 (2001) and later, because Gnulib's lib/regex.h
> + is always used and has this value. */
Or are we really guaranteed that even when we use gnulib's regex
module, we are using gnulib's regex.h but can still use the unreplaced
glibc implementations?
--
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization: qemu.org | libguestfs.org
