#10 Will fail to build with GCC 13 or 14 because of implicit ints and function declarations

[Petr Písař]

GCC 13 or 14 will start rejecting some C constructs in its default standard mode https://fedoraproject.org/wiki/Changes/PortingToModernC. Namely implicit ints and implicit function declarations will produce an error and prevent from building nas with that version of GCC. An attached patch fixes these problems. Please note that I only checked that the code builds. I did not do any functional tests.

A related warning: Future C standard will change meaning of an empty argument list in a function prototype (int foo()) from unknown, "variadic" aguments to no arguments (int foo(void)). I saw that NAS internal header files heavily use this old and deprecated feature. The fix is trivial, simply writing down the arguments to the prototypes. However, logging functions like ErrorF() rely on it to emulate variadic functions. Fixing these will mean to use va_start() and related macros, including va_copy(). va_copy() is available since C99 standard. Requiring C99 features could be a problem for NAS. One workaround for GCC and LLVM would be to select enforce an older compilation standard with a compiler option, e.g. -std=c89. This not an imminent problem, but it will materialize sooner or later. The attached patch does not address this issue.

[Jon Trulson]

Thanks for this patch. I've merged it to master.

As for ErrorF, perhaps that can be replaced by osLogMsg() which is used by the server - maybe that can be generalized and used for both client and server.

[Petr Písař]

Thanks for merging it. You can close this ticket.

[Eli Schwartz]

The patch modifies configure.ac, but configure is not regenerated and really should be.

(It currently does fail with an autoconf error: /usr/bin/m4:aclocal.m4:6178: cannot openacinclude.m4': No such file or directory`.)

[Petr Písař]

I excluded that generated file because it's content depends on third-party files the committer has in his system. Not being the maintainer, I cannot replicate that environment and the patch would be too big, obtrusive, and unhelpful. That means it's maintainer task to regenerate that file. Or, ideally, remove it from git repository.

You should be able to generate that file with a command like "autoreconf -i -f config", after installing automake, autoconf, libtool, and maybe other utilities.

[Eli Schwartz]

Well my problem was that it was asking for an m4 file that doesn't exist. I didn't expect the original patch to update configure -- just that the project maintainers should be ensuring they dont get out of sync.