Hi Junio, On Fri, 12 May 2017, Junio C Hamano wrote:
> Johannes Schindelin <[email protected]> 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 <stdint.h>" 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 <stdint.h> > > 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 <stdint.h> #include <wchar.h> typedef _sigset_t sigset_t; #endif and on this part of git-compat-util.h for MSVC builds: #ifndef NO_INTTYPES_H #include <inttypes.h> #else #include <stdint.h> #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 <regex.h>, which correctly #undefs RE_DUP_MAX and sets it to the right value. */ #include <limits.h> #include <stdint.h> 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. So yeah, I think you are right in that the HAVE_STDINT_H guard needs to be removed either before my patch, or squashed into it. Ciao, Dscho
