|
From: | Eric Blake |
Subject: | Re: pathmax: support for native Windows |
Date: | Tue, 13 Sep 2011 07:34:17 -0600 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110831 Fedora/3.1.12-2.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.12 |
On 09/13/2011 07:07 AM, Bastien ROUCARIES wrote:
On Tue, Sep 13, 2011 at 2:50 PM, Eric Blake<address@hidden> wrote:On 09/13/2011 06:47 AM, Bastien ROUCARIES wrote:PATH_MAX is this value for win32 name not for kernel name like \\?\c\. It is 32k in this case.When using kernel APIs (like cygwin does), then yes, the limit is 32k. But when using Windows APIs (like mingw and MSVC do), then you are better off using 260, which is the limit of windows APIs for all programs that do not bypass windows APIs in favor of kernel APIs. I see nothing to change here; gnulib is correct in using 260.Not sure according to http://msdn.microsoft.com/en-us/library/aa365247%28v=vs.85%29.aspx#nt_namespaces
PATH_MAX is the limit at which ENAMETOOLONG errors start occurring, and not necessarily a hard cap at which no name can be longer. It is also an allocation limit for which functions without array lengths will never exceed. For example, realpath() with a non-null buffer as the second argument must not exceed PATH_MAX bytes (you _must_ use NULL as the second argument to handle longer paths). Obviously, windows lacks realpath(), but if it were implemented, we would make realpath fail rather than return a \\?\c\ argument, in the case where a longer-than-260 byte name could be returned but where the user passed a non-NULL buffer. I still stand by my assertion that 260 is the right value for gnulib.
-- Eric Blake address@hidden +1-801-349-2682 Libvirt virtualization library http://libvirt.org
[Prev in Thread] | Current Thread | [Next in Thread] |