Fix lossage due to pathname truncation in calls to MODULE_LoadLibraryExA
michaelb at ieee.org
Thu Sep 12 22:16:54 CDT 2002
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
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.
More information about the wine-devel