User:Schievel/fixing clang16 errors

= Tipps an tricks for ancient code to modern C =

General workflow
(NOT as root user) I use compile here because sometimes the build creates some artifacts. I don't want to include the artifacts in the patch later, so I need them to be created before I initialize a git repo.
 * If the fix is not trivial I usually unpack the ebuild with
 * I go to the S directory, usually
 * I initialize a git repository in the workdir and commit everything in the workdir to one initial commit
 * Now I start working on the code. I can run (in the directory where the .ebuild is) (without clean!) to see what compiler errors still occur and what problems there are. I also start my LSP clangd in that repository which gives me additional hints.
 * when done I run to get my patch. This prints the patch into stdout. Be aware that patches sometimes fail when we copy them out of stdout (from the console) into another file. I haven't figured out what exactly is causing this, I assume it has something to do with line endings and such control characters. (like the CRLF vs. CR hassle with patches written on Windows) However this can be worked around by simply writing the output of   to a file, e.g. with
 * Patches should be cleaned up with  of . Also add a small description on top of the patch that this is for clang16, a link to the bug, if this patch was already sent to upstream and you as the author.

Fixing K&R C declarations
Often errors are caused by old K&R style function definitions. So this:

needs to be reworked into this:

This is not a very hard task, but I becomes exhausting when doing this for a larger project. can automate this. For a given file  cproto will convert (and return the prototypes of all functions it can find) with Or for all the .c-files in a project:

Fixing incompatible function pointer types
The code worked before, so usually those function pointers are not too far apart. An example on invalid function pointer types. Here is an example error for this: read-rl.c:113:36: error: incompatible function pointer types assigning to 'rl_completion_func_t *' (aka 'char **(*)(const char *, int, int)') from 'char **(char *, int, int)' [-Werror,-Wincompatible-function-pointer-types] This is caused by the given code snippet here: rl_attempted_completion_function = rl_esh_completion; Now,  is a   defined in the GNU readline utility: typedef char **rl_completion_func_t (const char *, int, int); While  is defined by this: static char** rl_esh_completion(char* word, int start, int end) (notice the missing const) Now, as the compiler message already suggested, this is easily solved by casting rl_esh_completion to the right type: return rl_completion_matches(word, (rl_compentry_func_t *)rl_find_builtin);

Fixing tricky function pointers declarations
An example warning for this would be: hash.c:162:6: warning: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype] func(he->data); ^ For this it is usually enough to put the variables into the function declaration. The code where func is defined is this: void hash_free(hash_table* tab,       void (*func)) { int i; list* iter; Now let's look up what type he->data is: hash_entry* he = (hash_entry*)(ls_data(iter)); and struct hash_entry { char* key; void* data; }; So he->data is a void*. So we need to declare a void* parameter as the first (and only) parameter of func: void hash_free(hash_table* tab,       void (*func)(void* data)) { int i; list* iter;

Fixing "possible configure breakage" bugs
Bugs like https://bugs.gentoo.org/879787 are often very easy to fix. Just put  and   in   into the ebuild. If the program uses autotools. If it uses some homebrew configure script we have to manually patch the configure. Generally speaking, if it is possible to use eautoreconf to fix a bug, it is preffered over patching a configure script. If we ever need to run eautoreconf in the future, we would have to make a new patch.

= See also =