Fix lossage due to pathname truncation in calls to MODULE_LoadLibraryExA

Michael Beach michaelb at
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.

> 	David


More information about the wine-devel mailing list