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 ...) Kind regards, Gero
