Re: [PATCH] sparse: ignore warning from new glibc headers

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

Đoàn Trần Công Danh <congdanhqx@gmail.com> writes:

> With at least glibc 2.39, glibc provides a function declaration that
> matches with this POSIX interface:
>
>     int regexec(const regex_t *restrict preg, const char *restrict string,
>            size_t nmatch, regmatch_t pmatch[restrict], int eflags);
>
> such prototype requires variable-length-array for `pmatch'.
> ...
> Thus, sparse reports this error:
>
>> ../add-patch.c: note: in included file (through ../git-compat-util.h):
>> /usr/include/regex.h:682:41: error: undefined identifier '__nmatch'
>> /usr/include/regex.h:682:41: error: bad constant expression type
>> /usr/include/regex.h:682:41: error: Variable length array is used.

I get the same with 

	$ sparse --version
	v0.6.4-66-g0196afe1

What I have locally in /usr/include may be a bit older.  It reads
like this:

        extern int regexec (const regex_t *_Restrict_ __preg,
                            const char *_Restrict_ __String, size_t __nmatch,
                            regmatch_t __pmatch[_Restrict_arr_
                                                _REGEX_NELTS (__nmatch)],
                            int __eflags);

where _Restrct_arr_ and _Restrict_ would become an empty string for
older compilers, and _REGEX_NELTS(foo) becomes empty when VLA is not
available.  I think their intention, when the compiler fully supports
all the necessary features, is to turn the fourth parameter into

	regmatch_t __pmatch[restrict __nmatch]

I can see how your patch forces the fourth parameter to become (ISO C99)

	regmatch_t __pmatch[restrict]

or even plain vanilla

	regmatch_t __pmatch[]

to erase the mention of __nmatch that is not understood by sparse.

> diff --git a/Makefile b/Makefile
> index bc81d3395032a..4b9daca1dcc58 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1381,7 +1381,7 @@ ARFLAGS = rcs
>  PTHREAD_CFLAGS =
>  
>  # For the 'sparse' target
> -SPARSE_FLAGS ?= -std=gnu99
> +SPARSE_FLAGS ?= -std=gnu99 -D__STDC_NO_VLA__
>  SP_EXTRA_FLAGS = -Wno-universal-initializer
>  
>  # For informing GIT-BUILD-OPTIONS of the SANITIZE=leak,address targets

But it makes me feel a bit dirty to define the macro that only
compiler implementations are expected to define (or not)[*1*] to
cause header files behave the way they would with a compiler without
VLA.  I dunno.

[Reference]

 *1* https://port70.net/~nsz/c/c11/n1570.html#6.10.8p2