Re: C11 / VS 2019

On 29.07.25 11:46, David Rowley wrote:
> ../src/backend/parser/gram.y:19362:12: error: call to undeclared
> function 'typeof'; ISO C99 and later do not support implicit function
> declarations [-Wimplicit-function-declaration]
>   19362 |                 result = copyObject(p->argType);
> 
> It's not quite clear to me why the C11 test passes but then the build
> fails. I assumed the mixed -std=gnu11 then -std=c99 are passed in the
> test as well. I don't know how to check.

The equivalent of config.log is in build/meson-logs/meson-log.txt.

> Strangely, if I swap the order of the c11_test_args so the test tries
> and uses -std=c11 first, it works ok.
> 
> @@ -558,7 +558,7 @@ if not cc.compiles(c11_test, name: 'C11')
>     if cc.get_id() == 'msvc'
>       c11_test_args = ['/std:c11']
>     else
> -    c11_test_args = ['-std=gnu11', '-std=c11']
> +    c11_test_args = ['-std=c11', '-std=gnu11']
>     endif

The situation is that with my original code, the C11 test picks the 
option -std=gnu11, and the typeof() test is then run with

cc ... -std=c99 ... -std=gnu11

which makes the test for typeof() pass (last option wins), but the 
actual build is run with

cc ... -std=gnu11 ... -std=c99

which disables the availability of typeof(), but pg_config.h says it's 
available, so the compilation fails.

If you flip the order of the arguments to be tested, then the C11 test 
picks -std=c11, and the typeof() test runs with

cc ... -std=c99 ... -std=c11

which will fail to detect typeof() (since it's neither in strict C99 nor 
in strict C11), and then later the actual compilation won't see typeof() 
at all.

Ideally, the tests should be run with the arguments in the same order as 
the actual compilation, but I don't think meson is equipped to support 
that.  I've been digging around the code and the documentation and don't 
find any mention about the *order* of the arguments supplied by various 
means like global, project, per-target, tests, environment, etc.  So I 
don't think there is any hope right now to sanely support "competing" 
arguments supplied from different sources.

(One might have valid concerns about -I and -L options, but that's a 
different potential topic.)

But since this is not how the patch was supposed to be used anyway, this 
shouldn't be a problem in practice.  It's not a new problem anyway.

FWIW, if you do this with autoconf, you get an early failure:

./configure CFLAGS='-std=c90'
...
checking for gcc option to accept ISO C89... none needed
checking for gcc option to accept ISO C99... unsupported
configure: error: C compiler "gcc" does not support C99

So putting "-std=" options into CFLAGS was never working.