On 09/13/2011 07:07 AM, Bastien ROUCARIES wrote:
On Tue, Sep 13, 2011 at 2:50 PM, Eric Blake<ebl...@redhat.com> 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 ebl...@redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
