Brief C23 excursion (was: Minor cleanup after adding more warnings to CFLAGS)

Am 16.04.26 um 06:52 schrieb Kevin J. McCarthy:
>
> So... I guess this is C23.  Which I know almost nothing about :-D.  In 
> any case, we're a long ways away from getting to that level of C 
> standard support in Mutt.

It's actually a C11 feature that is finally leveraged in the C23 
stdlib.h, see https://en.cppreference.com/w/c/language/generic.html or 
https://stackoverflow.com/questions/9804371/syntax-and-sample-usage-of-generic-in-c11 
or 
https://learn.microsoft.com/en-us/cpp/c-language/generic-selection?view=msvc-170

>
> So the only other alternative might be something like the other 
> approach of a "const char *" function and a "char *" wrapper.  I don't 
> insist on that though; it was just brainstorming.
>
There are two items everyone needs to know about C23 (a more complete 
but still concise overview is in the Android sources 
<https://android.googlesource.com/platform/bionic/+/HEAD/docs/c23.md>)

1. C23 CHANGES INCOMPATIBLY how a function _declaration_ without 
arguments is interpreted.

As of C23, int func() means the same as int func(void), must/will not 
take arguments, where C18 and before interpreted "has no prototype, any 
number of arguments is fine", although that had been deprecated since 
C99 or so.


2. GCC 15 (which is shipped by some mainline distributions) compiles C23 
by default, unless you tell it otherwise with an -std= option.


The practical impact is,

* it can break in code if there is very old code around that was not 
fully converted to provide prototypes everywhere,

* IT CHANGES THE RESULT of autoconf tests as a consequence,

It seems mutt's configure.ac is unaffected, but rest assured lots of 
AC_RUN_IFELSE (with AC_LINK_IFELSE, AC_COMPILE_IFELSE) and the preceding 
AC_TRY_LINK, AC_TRY_RUN and AC_TRY_COMPILE in lots of autotools projects 
with a long history are affected and then often mistakenly assess that 
some function or construct were unavailable.

* it can accept your code that is fine for a C23 or C++ compiler that 
will cause compiler diagnostics on C99, C11, C17/C18 compilers (example 
below).


For extensive distraction, there are two practical experiences from 
fetchmail that I fixed last year, for elucidation:

- Changing autoconf result between K&R/C89/C99/C11/C17 and C23 compilers:

AC_LANG_PROGRAM([[
/* ... */
#ifdef HAVE_RESOLV_H
#include <resolv.h>
#endif
extern int res_search();
/* ... */
]], [[res_search(0, 0, 0, 0, 0); dn_skipname(0,0);]])

The program would break in C23 because either the res_search() 
redeclaration was incompatible with the one in <resolv.h>, or the header 
was missing and HAVE_RESOLV_H undefined, and res_search() (being 
interpreted as res_search(void) in C23). It was used in AC_LINK_IFELSE 
and with C23 would believe res_search to be missing on the system.


- "compiler diagnostic on newly written code with older compilers" was 
here where I wrote a C23/C++ prototype (*) to a new clear_vis_buf() 
function that I needed to change to be valid C17/C11/C99, too: 
gitlab.com/fetchmail/fetchmail/-/commit/77fbbc8f5ef3fc6240de72c6e265036c7e3fb941 


(*: I write quite a bit of C++ in my paying job where int func() has 
meant the same as int func(void) aka "no arguments" for many years).