Re: [PATCH] compat/regex: fix compilation on Windows

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Junio,

On Fri, 12 May 2017, Junio C Hamano wrote:

> Johannes Schindelin <johannes.schindelin@gmx.de> 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