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).
