#1214 Build breaks with gcc-16 unless -std < c23 is specified

[Xavier Del Campo Romero]

C23 introduced a breaking change to the C language, specifically to function declarators without an explicit argument list (emphasis added):

For a function declarator without a parameter type list: the effect is as if it were declared with a
parameter type list consisting of the keyword void.

gcc-16 is apparently one of the compilers that forces C23 by default, breaking the build as of r5627:

../../gnucobol-svn-src/libcob/call.c: In function 'cob_call_cobol':
../../gnucobol-svn-src/libcob/call.c:1679:14: error: too many arguments to function 'unifunc.funcint'; expected 0, have 188
 1679 |         i =  unifunc.funcint (pargv[0], pargv[1], pargv[2], pargv[3]
      |              ^~~~~~~          ~~~~~~~~
In file included from ../../gnucobol-svn-src/libcob/coblocal.h:67,
                 from ../../gnucobol-svn-src/libcob/call.c:53:
../../gnucobol-svn-src/libcob/common.h:1335:27: note: declared here
 1335 |         int             (*funcint)();   /* Function returning "int" */
      |                           ^~~~~~~
../../gnucobol-svn-src/libcob/call.c: In function 'cob_call_entry':
../../gnucobol-svn-src/libcob/call.c:1788:14: error: too many arguments to function 'unifunc.funcint'; expected 0, have 188
 1788 |         i =  unifunc.funcint (pargv[0], pargv[1], pargv[2], pargv[3]
      |              ^~~~~~~          ~~~~~~~~
../../gnucobol-svn-src/libcob/common.h:1335:27: note: declared here
 1335 |         int             (*funcint)();   /* Function returning "int" */
      |                           ^~~~~~~

One possible workaround is to avoid C23 altogether, along with the breaking change, by adding -std=gnu99 to the CFLAGS.
OTOH given the fact that unifunc.funcint is meant to call a function with any number of arguments (from 16 up to 252 depending on MAX_CALL_FIELD_PARAMS), so I do not see any trivial solution that can still be C23-compliant.

[Simon Sobisch]

Correct - while that was GCC15 that changed the default, see https://gcc.gnu.org/gcc-15/porting_to.html#c23 Thanks for the report which is more on topic than the existing one, so I've closed the older in favor of this.

Note: The same issue exists with previous (released) versions.
I have at least a partial improvement, but the general issue with "any number" - as you've described, is hard to get completely right,

To compile for now, please add CFLAGS="-std=gnu17" for the configure line and, if needed also include -Wno-incompatible-pointer-types there.

[Xavier Del Campo Romero]

Thank you for the quick reply. According to my tests, -std=gnu99 also worked as expected, so maybe at this point GnuCOBOL should add this flag to its default CFLAGS in order to maintain compatibility with modern compilers.

OTOH to my understanding GnuCOBOL does not rely on any C11 or C17 features, so IMHO it would be wiser to rely on -std=gnu99 rather than -std=gnu17 in order to maintain compatibility with older compilers. WDYT @sf-mensch ?

[Simon Sobisch]

GnuCOBOL does not need newer options but may use them where reasonable. configure checks with whatever flags you pass to it and may enable/disable some features that way. Therefore I'd always specify the newest supported option.

Adding it to default CFLAGS will need a test in configure in any case - so we should first check if the void function declaration and pointer use works or not - and only try to work around that by specifying a std as-needed (and then try gnu17 / c17 / gnu11 /c11 / gnu99 / gnu89 / error) - if it isn't specified in "$CC$CFLAGS" already.

What do you think of trying to adjust configure.ac to do that, similar to the check for gc_cv_keyword_inline?