Re: mutt_buffer_concat_path is broken [PATCH: 1/1] Version 2

Alejandro Colomar via Mutt-dev <[email protected]> Fri, 8 May 2026 15:20:00 +0200

Newsgroups	gmane.mail.mutt.devel
Message-ID	<af3iSKUNg12ZOG-6@devuan>

Hi Derek,

On 2026-05-08T07:52:39-0400, Derek Martin wrote:
> On Fri, May 08, 2026 at 07:47:15AM -0400, Derek Martin wrote:
> > On Fri, May 08, 2026 at 08:08:13AM +0200, Rene Kita wrote:
> > > strspn is one of those function I can't get into my head, that's why I
> > > always end with a loop. :-) I should really try to remember it.
> > 
> > I prefer the loop:  They're functionally equivalent, nearly as
> > succinct, and far more explicit.  you're not the only one who has
> > trouble remembering it.  In professional production code I've seen
> > loops far more often than strspn.  Its name doesn't really lend to one
> > remembering what it does, like a lot of the less-commonly-used C
> > library functions.  =8^)
> 
> FWIW, it's also very slightly more efficient.  strspn will loop over
> the string, exactly as the while loop does, but a) it adds the
> overhead of the function call, and b) then after the call returns you
> have to do the pointer math to get where you want to go.  The while
> loop solution has neither cost.

I'd like to see evidence that compilers are unable to perform this
optimization these days.  Most likely, they know about strspn(3) and
optimize it as much as you could with a manual loop.

But even if I saw evidence (which I doubt), I think the fact that it
doesn't allow silly mistakes when writing the loop already counters the
small efficiency theoretical gains.


Cheers,
Alex

-- 
<https://www.alejandro-colomar.es>

signature.asc (application/pgp-signature, 833 B)