[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-wget] bad filenames (again)

From: Eli Zaretskii
Subject: Re: [Bug-wget] bad filenames (again)
Date: Thu, 20 Aug 2015 05:42:23 +0300

> Date: Wed, 19 Aug 2015 23:43:17 +0200
> From: Ángel González <address@hidden>
> CC: address@hidden
> On 19/08/15 16:38, Eli Zaretskii wrote:
> > Indeed.  Actually, there's no need to allocate memory dynamically,
> > neither will malloc nor with alloca, since Windows file names have
> > fixed size limitation that is known in advance.  So each conversion
> > function can use a fixed-sized local wchar_t array.  Doing that will
> > also avoid the need for 2 calls to MultiByteToWideChar, the first one
> > to find out how much space to allocate.
> Nope. These functions would receive full path names, so there's no 
> maximum length.*

Please see the URL I mentioned earlier in this thread: _all_ Windows
file-related APIs are limited to 260 characters, including the drive
letter and all the leading directories.

> * _Some_ Windows when using _some_ filesystems / apis have fixed limits, 
> but there are ways to produce larger paths...

The issue here is not whether the size limits differ, the issue is
whether the largest limit is still fixed.  And it is, on Windows.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]