This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] windows-nat.c: Cygwin: Port to Cygwin 1.7
On Feb 28 19:49, Eli Zaretskii wrote:
> > Date: Sun, 28 Feb 2010 18:18:28 +0100
> > From: Corinna Vinschen <vinschen@redhat.com>
> >
> > On Feb 28 19:08, Eli Zaretskii wrote:
> > > > Date: Sun, 28 Feb 2010 16:08:44 +0100
> > > > From: Corinna Vinschen <vinschen@redhat.com>
> > > >
> > > > - The maximum path length in Cygwin is no longer MAX_PATH. Rather it
> > > > is PATH_MAX, which is now 4096. Actually, even paths up to 32K are
> > > > supported, which is the maximum path length of the underlying Windows,
> > > > but usually 4K is more than enough.
> > >
> > > I'd suggest not to introduce arbitrary limits. If we are going to use
> > > the Unicode APIs, let's support the full 32K length they give us.
> >
> > Some buffers are on the stack and would have an unnecessary big size.
>
> I don't think 32K is too much for the Windows stack (but maybe it is
> with Cygwin; I don't know enough to judge). In Emacs, we had until a
> month ago code that used alloca to allocate a 700KB structure, and it
> worked in the native Windows build without any problems.
>
> > PATH_MAX, 4K, is more than enough especially since the names of DLLs
> > are stored in a buffer which is restricted to SO_NAME_MAX_PATH_SIZE,
> > which is 512 bytes ATM.
>
> I wasn't thinking about DLL names, I was thinking about source file
> names and names of executable programs.
The filename of executable and source files is not restricted to
PATH_MAX. The code in windows-nat.c only handles DLLs. Otherwise, see
utils.c, functions xfullpath() and gdb_realpath(). Cygwin provides the
canonicalize_file_name function.
Corinna
--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat