Re: Minor cleanup after adding more warnings to CFLAGS

Am 18.04.26 um 00:18 schrieb Steffen Nurpmeso:
> Matthias Andree via Mutt-dev wrote in
>   <[email protected]>:
>   |Am 17.04.26 um 05:26 schrieb Kevin J. McCarthy:
>   |> On Fri, Apr 17, 2026 at 02:31:19AM +0200, Alejandro Colomar via
>   |> Mutt-dev wrote:
>   |>> Yup, I meant how it can be done, not really an explanation of how the
>   |>> magic works.  I guess I should have explained it, as it's really not
>   |>> obvious.
>   |>
>   |> I know that explanation was for Steffen, but thank you.  I read your
>   |> code and explanation and links for a long while, before it started to
>   |> sink in.
>   |>
>   |> Steffen is right, it's really cool, but without your explanation I
>   |> never would have understood!
>   |
>   |The skills required to write library code and skills required to write
>   |application code differ by a large stretch. ;-)
>
> Well i mean .. i am just a Boche.  (But with a refrigerator
> not from Bosch, and unfortunately also not from Foron, but that
> aside.)
>
> I live in ISO C89 (or C99), and before, and overall mostly even in
> C++ '98, and my skills therein are so: i am alive and well.  (Even
> if Coverity now gives me some minor defect numbers instead of the
> 0.00 that i had once i actually uploaded a build last, and without
> giving me the defects that cause them.)  This includes compiling
> C with C++, just like with your project(s), as i see it; for me,
> at least those i wrote from scratch.

Unless you have truly persuasive reasons to stick to them because 
*outside* factors force you to, it's time to move to C11 and C++14 or 
17. Some of the reason as Alex suggested may not apply to mutt, and 
certainly C++ currently does not apply to mutt currently, but everyone 
stuck in last century of C or C++ should have another look on the new 
variants.

C11 closed some gaping holes that made programming close to hardware, or 
with portable datatypes, pretty awkward in older standard editions such 
as C99 or C89; C11 added portable alignment specification and querying, 
but also the type-generic programming already discussed helped. POSIX 
also progressed in the past two decades.


C++17 (and 11 before it and the 17 refinement after it) are really a 
quite different beast compared to what you did and could do last 
century, and teaching materials usually call C++11 and newer "Modern 
C++". There are some things to learn, but

     std::map<std::string, double> mymap { /* initialize here */ };

     for (const auto &[key, value] : mymap) {  /* do something useful 
with key and value */ }

could sell you the idea of how different the language has become even 
outside OOP. No more fiddling with writing your iterator over some heap 
or map, no more manual unpacking of pairs, no hassles with const as you 
see in C99 or before (or in the standard library near strings and memory 
areas).

The other area that C++ really helps with if you do it right (and use 
C++20's std::format, or the https://fmt.dev/ third party library that 
was largely the basis for the standard extension) to get proper and 
type-safe and by and large compile-time checked string formatting - 
instead of the error-prone sprintf family - is worth another look.  
  Boost used to be a thing, and it can play - usually portably - a few 
tricks that C++17, 14, 11 could not do, and it's still around, but it's 
far less needed as you move to newer C++ standards - many of the good 
things ended up in the standard. boost::filesystem became more or less 
verbatim C++17's std::filesystem.


Back to mutt, its codebase is currently not valid C++. It uses variable 
names that became reserved words in C++ (f.i., new, not, template, 
virtual) including as element names in structures, it uses designated 
initializers (a C++23 feature), will require several type casts 
(static_cast<target_type>(source_object) preferred) out of void*, too, 
and there's possibly a bit more. It's probably not too difficult to make 
it pass a C++23 down the road, but it's also no a paper cut or a 
five-minute task.