Re: pathmax: support for native Windows

[Eric Blake]

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