Error when building on Archlinux: call.c:1352:14: error: too many arguments to function ‘unifunc.funcint’; expected 0, have 188

[Edmund Lodewijks]

Hi all!

I am wanting to build gnucobol from the AUR on Archlinux, but I get the following error when not using a CFLAG "-std=gnu17":

call.c: In function ‘cob_call’:
call.c:1352:14: error: too many arguments to function ‘unifunc.funcint’; expected 0, have 188
 1352 |         i =  unifunc.funcint (pargv[0], pargv[1], pargv[2], pargv[3]
      |              ^~~~~~~          ~~~~~~~~
In file included from coblocal.h:52,
                 from call.c:51:
common.h:1179:27: note: declared here
 1179 |         int             (*funcint)();   /* Function returning "int" */
      |                           ^~~~~~~
make[2]: *** [Makefile:614: call.lo] Error 1

I would have liked to provide a patch, but I am afraid that that is a bit above my head. Could anyone please assist?

Some more context:
* gcc version 15.1.1 20250425 (GCC)
* build.log
* config.log
* trying to build GNUCobol 3.2 via AUR

Thank you very much!

[Simon Sobisch]

I'd need to do more testing, but you could either go down to -std=gnu99 or change all its use to cast to the correct type (that would also apply to codegen), possibly after changing libcob/common.h to

typedef union __cob_call_union {
    void        *(*funcptr)(void *);    /* Function returning "void *" */
    void        (*funcnull)(void *);    /* Function returning nothing */
    cob_field   *(*funcfld)(void *);    /* Function returning "cob_field *" */
    int     (*funcint)(void *); /* Function returning "int" */
    void        *funcvoid;  /* Redefine to "void *" */
#ifdef  _WIN32              /* stdcall variants */
    void        *(__stdcall *funcptr_std)(void *);
    void        (__stdcall *funcnull_std)(void *);
    cob_field   *(__stdcall *funcfld_std)(void *);
    int     (__stdcall *funcint_std)(void *);
#endif
} cob_call_union;

[Simon Sobisch]

Hm, reading the port notes at https://www.gnu.org/software/gcc//gcc-15/porting_to.html#c23-fn-decls-without-parameters seems to say that this does not happen with -std=gnu17 and testing their example on godbolt has indeed that error when compiled without -std (which means -std=gnu23 since GCC15 and meant -std=gnu17 in older versions)...

And checking config.log shows that there is no std set. Your adjustment to the arch package is also not correct per autotools documentation.

I suggest to change https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=gnucobol as follows:

    # Until fixed, the following CFLAGs are added:
-   CFLAGS="$CFLAGS -Wno-error=implicit-function-declaration -Wno-error=incompatible-pointer-types -std=gnu17" ./configure \
+   ./configure CC="gcc -std=gnu17" CFLAGS="$CFLAGS -Wno-error=implicit-function-declaration -Wno-error=incompatible-pointer-types" \
        --prefix=/usr \
        --infodir=/usr/share/info \
        --enable-static=no \
        --with-db \
        --with-json=json-c

You possibly also get around of not setting CFLAGS (I don't know) - ensure a working compiler by running make check during the build - I guess that's automatically done.

[Simon Sobisch]

Oh, and if you update the AUR package, you likely also want to include two important patches - see https://git.adelielinux.org/adelie/packages/-/commit/21fe3ef399c25f030d6657e83cc635335f3a9f40#435d163c05dbd4ff7d8a89cc0187a770d86666b7

[Edmund Lodewijks]

Please note that I am not a (C) programmer! Please check carefully over the below code sample and logic of it!

If I understand correctly, adding "void * " causes C to expect 1 argument. However, in the given case, many arguments are passed to the function. Therefore, I tried the following:

int     (*funcint)(void *, ...); /* Function returning "int" */

This, however, caused an issue in another section, when it tried to pass zero arguments, and now the function was expecting at least 1 argument.

I got it working by simply using the following, but I am not sure that this is correct.

int     (*funcint)(...); /* Function returning "int" */

I will look into the other suggestions you sent while I was typing this message. Thank you very much for your swift help!

[Edmund Lodewijks]

Just an update as to what I have done in the mean time, awaiting your feedback on the above.

• I moved -std=gnu17 to outside CFLAGS (thanks!)
• I added the two patches from Adelie Linux
• I enabled the make check and make test suite. There are a LOT of errors on my build. I suppose many are due to warnings. See an example below:

cat src/gnucobol-3.2/tests/testsuite.dir/1213/testsuite.log 
#                             -*- compilation -*-
1213. run_extensions.at:6100: testing INSPECT REPLACING TRAILING ZEROS BY SPACES ...
./run_extensions.at:6116: $COMPILE prog.cob
--- /dev/null   2025-05-03 12:02:33.041363906 +0200
+++ [REDACTED]/builds/aur/gnucobol/src/gnucobol-3.2/tests/testsuite.dir/at-groups/1213/stderr   2025-05-03 21:22:53.760523947 +0200
@@ -0,0 +1,13 @@
+In file included from /usr/include/bits/libc-header-start.h:33,
+                 from /usr/include/string.h:26,
+                 from /tmp/cob318316_0.c:8:
+/usr/include/features.h:435:4: warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Wcpp]
+  435 | #  warning _FORTIFY_SOURCE requires compiling with optimization (-O)
+      |    ^~~~~~~
+/tmp/cob318316_0.c: In function 'prog_module_init':
+/tmp/cob318316_0.c:219:32: warning: assignment to 'void * (*)(void *)' from incompatible pointer type 'void * (*)(void)' [-Wincompatible-pointer-types]
+  219 |   module->module_entry.funcptr = (void *(*)())prog;
+      |                                ^
+/tmp/cob318316_0.c:220:33: warning: assignment to 'void * (*)(void *)' from incompatible pointer type 'void * (*)(void)' [-Wincompatible-pointer-types]
+  220 |   module->module_cancel.funcptr = (void *(*)())prog_;
+      |                                 ^
1213. run_extensions.at:6100: 1213. INSPECT REPLACING TRAILING ZEROS BY SPACES (run_extensions.at:6100): FAILED (run_extensions.at:6116)

[Simon Sobisch]

You definitely want to:

• add CFLAGS="-Wincompatible-pointer-types" to your configure line (as that is a "precious" var, pass it to configure, not exporting it
• use one of --enable-hardening (will keep fortification and enable -O, possibly add more hardening options) of --disable-hardening (background: your build environment defines the fortification and likely -O by default, but we drop the -O normally for COBOL modules if you don't use cobc -O)

[Edmund Lodewijks]

Thank you for the explanations!
* I learned a bit about "precious" variables, and will amend some other PKGBUILDs I maintain.
* I was surprised that the standard hardening options from my system were not applied, despite their being set on the ./configure line. Now I understand that some are dropped automatically, and --enable-hardening must be set.

My current PKGBUILD for gnucobol contains the following for ./configure:

        ./configure \
                CC="gcc -std=gnu23" \
                CFLAGS="$CFLAGS -Wno-error=implicit-function-declaration -Wno-error=incompatible-pointer-types" \
                --prefix=/usr \
                --infodir=/usr/share/info \
                --enable-hardening \
                --enable-static=no \
                --with-db \
                --with-json=json-c

The "std=gnu23" is currently only there so that I can quickly change to gnu17 for testing. Ideally it will be removed in the end.

[Simon Sobisch]

The original one is "zero to unlimited arguments" until C23 where it is identical to (void) - exactly zero arguments.
anything with ... is a variadic argument list - those are placed differently on the stack and won't work with functions that have for example 4 parameters.

The goal here is to increase type safety if no explicit casts are done. I'll possibly inspect the optional use of libffi in a bunch of days, but I guess that this may only work correctly (for COBOL where you may omit trailing OPTIONAL arguments) if the previously loaded caller provides metadata about the amount of arguments - and those are used... which is actually a good idea for 4.x, so maybe I inspect libffi "more later"...

What I may do earlier is replacing the union by a simple void *func (void) and then always cast... but I may have tried that before running into compiler warnings (clang?) about "bad practice, may break at runtime".

[Edmund Lodewijks]

Thank you for these explanations.

I will revert the ... and await any further info from you. In the meantime, I can also simply add the CC="gcc -std=gnu17" line. Is GnuCOBOL v3 still developed, or is development supposed to only go into v4, meaning that you would rather spend your time on v4?

[Simon Sobisch]

We (@ddeclerck does the work and necessary adjustments, I'm doing the review) are in the process of merging 3.x to 4.x. In any case there will be a 3.3 release this year (maybe in 2 months) and I'm indeed mostly working on the 3.x branch. It is not clear yet if 3.3 will be the last release of the 3.x version, but focus will go to 4 as well as V-ISAM after its release.

Note: 3.2 had translation updates, you possibly want to update French, German and Serbian manually. Side note: I'll drop any translation from the distribution that doesn't have more than 50% translated before the 3.3 release, so Spanish, Turkish and Swedish may or may not stay in (depending on translators which I'll send a friendly ping after the first 3.3rc).

[Edmund Lodewijks]

Thanks!

I looked at Gentoo, and they have a patch for C23. I can't judge it and will just leave it here.