Fix lossage due to pathname truncation in calls to MODULE_LoadLibraryExA

[Michael Beach]

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/naming_a_file.asp 
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