On Friday 13 September 2002 09:13, David Laight wrote:
I was under the impression that MAX_PATH is a Windows limitation rather than one of the UNIX that WINE is running on. Since Windows doesn't promise to permit any more than MAX_PATH, we gain nothing by allowing for more in WINE, hence the use of MAX_PATH to size the buffers.
Dunno about widnows, but posix and unix claim to have a PATH_MAX. Unix file system code doesn't usually check (after all it would have to know the max depth at any point - otherwise you could rename a directory and exceed the limit way down the file tree).
Well, I don't think it's intended to enforce a bound on the maximum length of any possible path, but rather the maximum size of a pathname that you can pass as an argument to stuff like open() or stat(). I formed this impression by reading the sections on limits.h and pathconf() in the Open Group (aka POSIX, more or less) specs at http://www.opengroup.org/onlinepubs/007904975/toc.htm
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base... mentions the role of MAX_PATH in Windows. A peek in the headers shows that it has the value of 260.
It is the sort of limit that is rather painful - you either allocate a massive (on stack) buffer most of which is never needed (and traditiobally fail to check for overflow) or dynamically allocate a buffer that is big enough and don't have a limit at all.
Yes, a pain, but I think the APIs oblige us to take the conservatively sized on-stack buffer option.
David
Regards M.Beach