Corinna Vinschen wrote:
> Urgh. MAX_PATH is defined with trailing 0, SYMLINK_MAX is defined
> without trailing 0 (like NAME_MAX). You should better change the
> SYMLINK_MAX stuff back, afaics...
D'oh! 'Kay.
On Mar 11 10:07, Brian Dessent wrote:
> Corinna Vinschen wrote:
>
> > Btw., you don't need to make the buffers MAX_PATH + 1. MAX_PATH is
> > defined including the trailing NUL. Existing code shows a lot of
> > irritation about this...
>
> Oh, I wasn't even thinking of that... the reason I used
Corinna Vinschen wrote:
> Btw., you don't need to make the buffers MAX_PATH + 1. MAX_PATH is
> defined including the trailing NUL. Existing code shows a lot of
> irritation about this...
Oh, I wasn't even thinking of that... the reason I used MAX_PATH + 1 was
because earlier I had written
+
On Mar 11 08:36, Brian Dessent wrote:
> Corinna Vinschen wrote:
>
> > Given that Cygwin changes to support long path names, I don't really
> > like to see new code still using MAX_PATH and Win32 Ansi functions
> > in the utils dir. I know that the Win32 cwd is always restricted to
> > 259 chars.
Corinna Vinschen wrote:
> Given that Cygwin changes to support long path names, I don't really
> like to see new code still using MAX_PATH and Win32 Ansi functions
> in the utils dir. I know that the Win32 cwd is always restricted to
> 259 chars. However, there *is* a way to recognize the curren
On Mar 10 21:10, Corinna Vinschen wrote:
> On Mar 10 15:08, Christopher Faylor wrote:
> > However, I don't understand what a mingw app would see when it is started
> > from Cygwin now. What would a standard windows app think that its cwd would
> > be if it's cd'ed deep into a 32K long path.
>
> R
