Re: [PATCH] git-compat-util: Avoid strcasecmp() being inlined

[Junio C Hamano <gitster@pobox.com>]

Sebastian Schuberth <sschuberth@gmail.com> writes:

> Well, if by "everywhere" in (1) you mean "on all platforms" then
> you're right. But my patch does not define __NO_INLINE__ globally, but
> only at the time string.h / strings.h is included. Afterwards
> __NO_INLINE__ is undefined. In that sense, __NO_INLINE__ is not
> defined "everywhere".

Which means people who do want to see that macro defined will be
broken after that section of the header file which unconditionally
undefs it, right?

That is exactly why that change should not appear in the platform
neutral part of the header file.

> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -85,12 +85,16 @@
>  #define _NETBSD_SOURCE 1
>  #define _SGI_SOURCE 1
>
> +#ifdef __MINGW32__
>  #define __NO_INLINE__ /* do not inline strcasecmp() */
> +#endif
>  #include <string.h>
> +#ifdef __MINGW32__
> +#undef __NO_INLINE__
> +#endif

That is certainly better than the unconditional one, but I wonder if
it is an option to add compat/mingw/string.h without doing the
above, though.

That header file can do the "no-inline" dance before including the
real thing with "#include_next", and nobody else would notice, no?

	#ifdef __NO_INLINE__
        #define __NO_INLINE_WAS_THERE 1
        #else
        #define __NO_INLINE__
        #define __NO_INLINE_WAS_THERE 0
	#endif

	#include_next <string.h>
        #if !__NO_INLINE_WAS_THERE
        #undef __NO_INLINE__
	#endif

or something like that.

That of course assumes nobody compiles for _MINGW32_ with a compiler
that does not understrand "#include_next" and I do not know if that
restriction is a showstopper or not.



>  #ifdef HAVE_STRINGS_H
>  #include <strings.h> /* for strcasecmp() */
>  #endif
> -#undef __NO_INLINE__
>
>  #ifdef WIN32 /* Both MinGW and MSVC */
>  #ifndef _WIN32_WINNT