Hi, On Friday, 2017-09-15 13:02:25 -0500, Derek Martin wrote:
> On Fri, Sep 15, 2017 at 09:43:58AM -0700, Kevin J. McCarthy wrote: > > On Fri, Sep 15, 2017 at 12:58:18AM +0200, Eike Rathke wrote: > > > Maybe path related destination buffers also shouldn't be > > > of _POSIX_PATH_MAX but PATH_MAX size instead. > > > > 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? *If* defined then PATH_MAX is *usually* larger than _POSIX_PATH_MAX (which usually is defined to 256 including null char). Though it still (for some file systems) does not represent the maximum length a path specifier may actually have. However, _POSIX_PATH_MAX is the maximum length a file name or directory name is assumed to have, not the entire path. > PATH_MAX is highly system dependent, and in many cases, also > completely bogus. Relying on it is often folly, but it's also often > all you really can do. True. Or just use an own destination buffer size of 64kB for (recursive) concatenation ... a later stat() or open() would fail if too long. Eike -- OpenPGP/GnuPG encrypted mail preferred in all private communication. GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A Care about Free Software, support the FSFE https://fsfe.org/support/?erack Use LibreOffice! https://www.libreoffice.org/
signature.asc
Description: PGP signature
