Fix a few minor compiler/standards issues (clang-16 porting) (0.103.9)#747
Fix a few minor compiler/standards issues (clang-16 porting) (0.103.9)#747val-ms merged 2 commits intoCisco-Talos:dev/0.103.9from orlitzky:clang-16
Conversation
|
Thanks for submitting this. Skimming over the changes it all looks good to me. We don't commit new development directly to our release branches, so I've created I also don't like to merge PR's into a development branch until we've changed the clam version number in that branch, so even once this is tested, we'll hold off until that is done. |
Yes, probably. We have two similar bugs reported against v0.105.x (871252, 879625), but I'm only maintaining the LTS these days. If you're feeling proactive, you can try to build the main branch yourself with those three
No problem. Thanks. |
val-ms
changed the title
|
Ugh. We didn't merge this before releasing 0.103.8. I'm sorry. We can try to put this towards 0.103.9. At least we did merge the one that went into main towards future versions. |
val-ms
changed the title
|
NBD. Clang 16 is expected "any day now" so I was peer pressured into patching v0.103.8. But with the LTS series on life-support-only the patches aren't that hard to manage. |
On Linux, thpool.c uses syscall() from unistd.h, but that function is not defined without _GNU_SOURCE: c-thread-pool/thpool.c: In function 'jobqueue_pull': c-thread-pool/thpool.c:474:105: error: implicit declaration of function 'syscall' [-Werror=implicit-function-declaration] In general that's not great, because it hinders some compiler diagnostics, but it will also cause problems down the road if (for example) clang-16 decides to enable -Werror=implicit-function-declaration by default. This commit changes the _POSIX_C_SOURCE definition at the top of thpool.c to _GNU_SOURCE, as in the syscall(2) man page.
Prototypes (or the declarations themselves, if there is no
corresponding prototype) for functions that take no arguments are
required by the C standard to specify (void) as their argument list;
for example,
regex_pcre.h:79:1: error: function declaration isn't a prototype
[-Werror=strict-prototypes]
79 | cl_error_t cli_pcre_init_internal();
Future versions of clang may become strict about this, and there's no
harm in conforming to the standard right now, so we fix all such
instances in this commit.
3 participants
The next major version of clang has threatened to enable some strictness flags by default:
https://bugs.gentoo.org/show_bug.cgi?id=clang-16-porting
Specifically,
Whether or not they all wind up on by default, the problems they catch are easy to fix and usually beneficial for e.g. further compiler diagnostics. Here I've fixed what I had to in order to build v0.103.7.
For the autotools build system, the following autoconf fix (and an
autoreconf -fi) is also required:https://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commit;h=8b5e2016c7ed2d67f31b03a3d2e361858ff5299b
Otherwise, the checks that are emitted will unduly fail.