Hi, On Fri, Feb 06, 2026 at 03:39:22PM +0100, Gero Treuner wrote: > Hi all, > > On Fri, Feb 06, 2026 at 02:37:36PM +0100, Alejandro Colomar via Mutt-dev > wrote: > > > > However, I personally argue for code clarity except when optimization is > > > > called for. In this case, I don't think it's worth the trade off. See > > > > just > > > > below the function in mh.c, mx_is_mh(), for similar code, also called by > > > > mx_get_magic(). > > > > > > > > As always, if others disagree please just say so. > > > > > > personally I see it the same way, considering readability and simplicity > > > a big priority; parsing the proposed version is (at least for me) much > > > harder than the original version. > > > > +1 > > > > Except that maybe with fstatat(2) (as Crystal said) it could be readable > > --we'd have to see the code, though--. > > > > readability >>> optimizations > > Thank you and others for the feedback. > > A quick research shows that fstatat(2) isn't a good option: > > 1) Even on Linux it was introduced no earlier than with glibc 2.4, so > this makes a case for portability fiddling with automake etc. > > 2) The directory needs to be opened with a file descriptor, which adds > resource handling. > I don't see consistency of the directory in the event that by > mounting etc. the file system changes as a benefit here. IMO it is > fine to fail for a test of a mail folder when something looks fishy. > (Otherwise the test could succeed for a place which isn't available > any more.) > > But the same gain of readability could probably be achieved by other > means. (Let's see when I'll come back to puzzling ...)
If we can't have fstatat(2), I honsetly prefer the inefficient version. I'd be surprised to change my mind on that. Cheers, Alex > > > Kind regards, > Gero -- <https://www.alejandro-colomar.es> Use port 80 (that is, <...:80/>).
signature.asc
Description: PGP signature
