Hi Oswald,
On Sun, Jan 25, 2026 at 11:59:42AM +0100, Oswald Buddenhagen via Mutt-dev wrote:
> On Sun, Jan 25, 2026 at 06:09:39PM +0800, Kevin J. McCarthy wrote:
> > +static int is_from_reverse_scan (const char * const bos,
> > + char *path, size_t pathlen,
> > + struct tm *tm)
> > +{
> > + const char *cur = bos;
> > +
> that assignment is pointless.
>
> > + cur = strchr (bos, '\0');
> > +
> that's kinda inefficient, as strchr already checks for null.
> faster and arguably more legible would be `bos + strlen(bos)`.
>
> also, as this is arguably performance-critical code, it may make sense to
> pass in the length from the layer above.
Is it so critical that strlen(3) would be a problem? I expect usual
From lines to be quite short, and thus calling it wouldn't matter.
(And if one has a huge message where this might matter, it probably has
more important problems to deal with than an strlen(3) call.)
I'd be worried if the length were calculated too far from its use, as
that increases chances of human mistakes and thus bugs.
Have a lovely day!
Alex
> > + { "mbox_lax_parse", DT_BOOL, R_NONE, {.l=OPTMBOXLAXPARSE}, {.l=1} },
> > + /*
> > + ** .pp
> > + ** This version of the mbox parser allows more loose return path values
> > in the
> > + ** From_ line.
> > + */
> this is way too cryptic and unspecific. without knowing the context, one
> would be left guessing why one might want to touch it.
>
> but more generally, i'm not convinced that an option is a terribly good
> idea. once one sets it, the silent failures will resume, no?
>
--
<https://www.alejandro-colomar.es>
signature.asc
Description: PGP signature
