From: Ramsay Jones Date: Fri, 12 May 2017 21:02:58 GMT Subject: Re: [PATCH] compat/regex: fix compilation on Windows Message-ID: <413493c2-24ee-e085-f4cc-371b677d2d02@ramsayjones.plus.com> In-Reply-To: On 12/05/17 11:25, Johannes Schindelin wrote: > Hi Junio, > > On Fri, 12 May 2017, Junio C Hamano wrote: > >> Johannes Schindelin writes: >> >>> The real issue here is that GNU awk's regex implementation assumes a >>> bit too much about the relative sizes of pointers and long integers. >>> What they really want is to use intptr_t. >> >> Good. I got annoyed enough to do the same myself before opening my >> mailbox. One thing that is curious about your version is that it still >> has "#include " behind HAVE_STDINT_H; when I tried to compile >> an equivalent of your change last night, the compilation failed because >> intptr_t wasn't available without exposing >> >> Where is Windows build getting its intptr_t, I wonder. > > I'd place a bet on this part of compat/mingw.h for GCC builds: > > #ifdef __MINGW64_VERSION_MAJOR > #include > #include > typedef _sigset_t sigset_t; > #endif > > and on this part of git-compat-util.h for MSVC builds: > > #ifndef NO_INTTYPES_H > #include > #else > #include > #endif > > For the record, it seems that our current version of compat/regex/regex.c > has this: > > /* On some systems, limits.h sets RE_DUP_MAX to a lower value than > GNU regex allows. Include it before , which correctly > #undefs RE_DUP_MAX and sets it to the right value. */ > #include > #include > > while the one in `pu` lacks the last line. That may be the reason why > things compiled neatly before, and stopped working for you now. Yep, see commit bd8f005583. ;-P So, sparse is, once again, complaining about the SIZE_MAX macro redefinition. (Along with two other warnings, one of which is a _very_ long standing warning and one of which is new - I have yet to investigate). ATB, Ramsay Jones