On Fri, Sep 15, 2017 at 12:58:18AM +0200, Eike Rathke wrote: > This is nothing overly critical (not even in mutt_rmtree() if > a truncated string also represents an existing directory entry, as there > was a checked opendir(path) and all entries are to be removed, but > truncated will not be removed as intended, so..), just a heads-up that > some long paths may get truncated when concatenating into a buffer. > Places that do such concatenation using snprintf() should check the > return value and if greater or equal than size(...) it means the result > is truncated. Maybe path related destination buffers also shouldn't be > of _POSIX_PATH_MAX but PATH_MAX size instead.
Thanks Eike. I'll put this on my list to look at when I have some time. (I've been crazy busy recently). In general, this is a string I'm not too anxious to pull on (pun intended), because Mutt uses fixed sized buffers for a lot of this stuff. Sometimes the truncation is bad, but there are a few instances where truncation is just fine and even planned for in the code. It looks like Mutt uses _POSIX_PATH_MAX in the majority of cases with just a sprinkle of PATH_MAX uses. Is PATH_MAX generally larger? -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
