Đoàn Trần Công Danh <congdanhqx@xxxxxxxxx> 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
