On Tue, Nov 30, 2010 at 01:29:31PM +0100, Johannes WeiÃl wrote:
> On Tue, Nov 30, 2010 at 12:42:44PM +0100, Bertrand Yvain wrote:
> > mutt should use PATH_MAX instead of _POSIX_PATH_MAX, this would allow to
> > push the boundary to the actuel limit of your system.
>
> yes, I also thought so! But of course that would lead to path-type
> variables of length 4096 on many systems, causing another imbalance
> with string-type variables. Is there a reason why mutt uses
> _POSIX_PATH_MAX (besides historical ones)?
The maximum length of string variables is an issue internal to mutt.
There is a tricky part with using PATH_MAX. Quoting POSIX 2008 [1]:
: The values in the following list may be constants within an
: implementation or may vary from one pathname to another. For example,
: file systems or directories may have different characteristics.
: {PATH_MAX}
: Maximum number of bytes the implementation will store as a pathname
: in a user-supplied buffer of unspecified size, including the
: terminating null character. Minimum number the implementation will
: accept as the maximum number of bytes in a pathname.
: Minimum Acceptable Value: {_POSIX_PATH_MAX}
: [XSI] Minimum Acceptable Value: {_XOPEN_PATH_MAX}
So PATH_MAX is not really compatible with static/automatic allocation
unless path are consistently absolute or relative to the same directory.
I see _POSIX_PATH_MAX as the safe choice (without XSI conformance).
[1] http://www.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html
--
Bertrand Yvain
http://www.IELO.net/
Attachment:
signature.asc
Description: Digital signature