Choice of C language mode: C99 on Linux despite C99 incompatibilities

[fweimer-rh]

config/LINUX contains this:

#define CcOptions      -ansi -fPIC -fopenmp -std=c99

However, the sources contain dozens of instances were C language constructs are not part of C99. This can be seen from compiler warnings:

closure.c:11:1: error: type defaults to 'int' in declaration of 'set_EFF'
   11 | set_EFF()
      | ^~~~~~~
closure.c: In function 'set_EFF':
closure.c:39:5: error: implicit declaration of function 'reflexive_transitive_closure'
   39 |     reflexive_transitive_closure(EFF, nvars);
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~

Future versions of GCC may turn these into errors, to match the spirit of the C99 standard. Could you build in C89 mode instead (maybe -std=gnu89, so C89 with more GNU extensions)?

Thanks, Florian

PS: Downstream tracking bug: https://bugzilla.redhat.com/show_bug.cgi?id=2145150

[ryandesign]

Future versions of GCC may turn these into errors

Apple clang 12 and later and llvm.org clang 16 and later already do consider implicit declaration of functions to be an error. llvm.org clang does this in C99 and later modes and using C89 mode would be a successful workaround, however Apple clang also does this in C89 mode. The way to suppress the error for either compiler would be to add -Wno-error=implicit-function-declaration to CFLAGS, but suppressing the error will no longer be possible as of C20. The best idea is not to attempt to suppress the error. It was made an error for a reason. Instead, fix it by declaring functions before using them.

The latest Apple and llvm.org clangs also consider implicit int to be an error, and the best idea is to fix it by explicitly specifying function return types and argument names and types.

The downstream tracking bug for MacPorts: https://trac.macports.org/ticket/67455