Am 08.05.26 um 18:25 schrieb Derek Martin:
On Fri, May 08, 2026 at 05:25:24PM +0200, Alejandro Colomar via Mutt-dev wrote:
Here's my experiment compiling exactly your code with GCC 15:
$ gcc --version
gcc (Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0
This is on Ubuntu LTS 24.04. Availability != ubiquity. I expect gcc
15 won't be in widespread use for years yet. I also expect, but do
not know for a fact, that major distros are compiling their software
with the same compiler they are shipping in the distro.
Also, I know of no projects that use -O3 (mutt certainly doesn't),
typically because it complicates debugging (even more than -O2 already
does) and IIRC can in some circumstances produce incorrect/unexpected
behavior. This may (or may not) be because such programs depend on
undefined behavior, but a lot of real-world code has such things, even
as written by seasoned pros. ^_^
Performance aside, IMO you saved a handful of characters at the
expense of a non-standard wrapper around an infrequently-used
interface, adding an extra level of indirection, sacrificing a degree
of clarity for a tiny increase in succinctness. I don't think that's
a good trade. As I said elsewhere, the lack of clarity of the cases
was the main reason I raised this issue in the first place (though the
potential for segfault was also an important factor, now moot).
Myths, old doubts, uncertainty, fear, old scare-tales...
Just because Ubuntu "LTS" (where LTS only applies to "main" series code,
not the universe that any serious use usually implies) is constantly
10...30 months behind the release, does not make it the authority over
what's to be used and what not. It's certainly not where upstream future
free and open source should limit itself. Old distros (note that Ubuntu
26.04 LTS has been released in April) will not upgrade mutt at all, so
why are they relevant for the leading release of some independent
project as mutt?
It doesn't matter for C99 or C11 as much as it does for modern C++
dialects - but usually staying with old compilers and libraries is
weakly motivated at best and usually a wasted opportunity - but as long
as the codebase is something like C11 or similar it doesn't make a huge
difference either.
And also just because you haven't found -gdwarf-5 -ggdb3
-fno-omit-frame-pointer, you needn't retell the old untrue scary tale it
were useless for debugging. You'll probably also advise me to use -O0
for debug stuff when -Og with GCC is the right approach these days.
-O3 will tweak optimization parameters a bit, and I hear Ubuntu has a
PPA enabling recent toolchains for those who want or need to use them,
so stop gluing everyone in the past. GCC 15 is readily available, but
that's also rather irrelevant for C code unless you're using one of the
recent dialects, which mutt does not do yet. Yet -O3 -flto should
usually be the simple approach. Remember we're not trying to fit lunar
lander software into a few kbytes of memory here, or a new customer
request into an embedded device years after start of production.
Arguing to avoid optimisers because you're concerned about a potential
bug is usually a sign that you should recompile with a proper warning
level and possibly the undefined behaviour sanitizer so you fix those
oversights. Not that optimization makes a lot of difference for mutt
either. Usually the crucial point is avoiding stupid things, first and
foremost anything O(n²) or worse. Micro-benchmarking stuff that hasn't
been proven to be a hot but slow path is also wasted time.
So, strspn isn't unrolled into direct assembly, it might be so in a
future libc version or on a future compiler, and the loop is a touch
faster for me at high optimization than the function call, because the
code links to an external strspn function and goes through the PLT. -O3
gets rid of it because calling it several times on the same string is
idempotent, and idempotent means that f(f(x)) === f(x), OTOH
benchmarking something trivial isn't very relevant.
That all being said, thanks for poking at mutt_buffer_concat_path and
fixing it.
If mutt were to call strspn a hundred million times to deal with
filenames however, something else would be seriously hosed and it would
be worth avoiding so many calls to something that can be reused instead
of micro-optimizing the callee.
