Since commit 54dd0ab31fe2b2168ba1a6180a0c05941fb54b3c, the MAX macro is used in regex_internal.c which is included by regex.c, while it is not defined on the include on Hurd. On other architectures it is define in <sys/param.h> which is included in a weird way: from ../sysdeps/i386/i686/hp-timing.h:25, from ../sysdeps/x86_64/hp-timing.h:23, from ../nptl/descr.h:28, from ../nptl/sysdeps/x86_64/tls.h:98, from ../include/tls.h:6, from ../bits/libc-tsd.h:45, from ../locale/localeinfo.h:210, from regex.c:54 I think that it should be included directly in regex_internal.h instead. Patch will follow.
Created attachment 4818 [details] Patch to fix the problem
Created attachment 6224 [details] * posix/regex_internal.h (MAX, MIN): Define if not already defined.
I have attached the patch that Gnulib uses for this problem: it's more portable, as it doesn't assume that <sys/param.h> exists or that <sys/param.h> defines MIN and MAX. regex_internal.h is used outside glibc so it needs to be a bit more portable.
This had just come up on libc-alpha again: <http://sourceware.org/ml/libc-alpha/2012-02/msg00324.html>. I hadn't realized these are imported/shared files. (Shouldn't this be mentioned somewhere prominently?) In this case, we'd go with the upstream fix, obviously. But -- Paul, please have another look at your MIN definition... ;-P
On Fri, 17 Feb 2012, tschwinge at sourceware dot org wrote: > I hadn't realized these are imported/shared files. (Shouldn't this be > mentioned somewhere prominently?) In this case, we'd go with the I think gnulib's config/srclist.txt is the master list of files gnulib gets from elsewhere, including those it gets from glibc. It's not perfect - as I previously noted, gnulib's getcwd.c appears to be from glibc but isn't listed there. And, various entries therein are commented out with references to glibc bugs that are marked as FIXED - so whatever the current reasons for those files not being fully in sync with glibc, the lists of bugs in comments aren't particularly helpful. I'd like to see these files more fully in sync between glibc and gnulib again (as I said in <http://sourceware.org/ml/libc-alpha/2012-01/msg00123.html>, the only differences that seem essential are the gnulib changes to license headers and gnulib's use of spaces instead of tabs for indentation, and those are presumably handled automatically by the gnulib mechanism for updating from external projects). But as noted in <http://sourceware.org/ml/libc-alpha/2012-01/msg00129.html> and <http://sourceware.org/ml/libc-alpha/2012-01/msg00128.html> this does require gnulib maintainers to send lots of individual logical patches to resync things. For the shared files, it's generally glibc that is supposed to be the master, not gnulib.
Created attachment 6230 [details] Corrected patch from gnulib Thanks, Thomas, for catching the cut-and-paste bug in my previous patch. Here is a revised version, which supersedes the old proposal.
(In reply to comment #5) > For the shared files, it's generally glibc that is supposed to be the > master, not gnulib. I agree with everything in Joseph's comment, including the fact that glibc is supposed to be the master. I plead lack of time in trying to bring things up to sync. My current project is to sync the regex code of glibc, gnulib, and Emacs, and at the rate I'm going it'll take months, if not years, to finish. Admittedly this may be the worst case but still it'd be nice if we could make it easier to sync.
Fixed as part of Roland's commit bea9b19322c77265033a068ac60c95a37e798a80 »Fix lots of bitrot for stub configurations.«: [...] * posix/regex.c: Include <sys/param.h> for MIN/MAX. [...] In NEWS marked as fixed in commit 512a49be20d42af59968513cd5094b3918cf6663. Conciliating the different versions of this regex implementation (which Paul said he is working on) is a different matter.