From: René Scharfe <l.s.r@web.de>
Date: Fri, 18 Jul 2014 11:32:59 GMT
Subject: Re: [PATCH] abspath.c: use PATH_MAX in real_path_internal()
Message-ID: <53C905EB.3010908@web.de>
In-Reply-To: <53C8562C.4000304@gmail.com>

Am 18.07.2014 01:03, schrieb Karsten Blees:
> Am 17.07.2014 19:05, schrieb René Scharfe:
>> Am 17.07.2014 14:45, schrieb Nguyễn Thái Ngọc Duy:
> [...]
>> "These routines have traditionally been used by programs to save the
>> name of a working directory for the purpose of returning to it. A much
>> faster and less error-prone method of accomplishing this is to open the
>> current directory (.) and use the fchdir(2) function to return."
>>
>
> fchdir() is part of the POSIX-XSI extension, as is realpath(). So why not
> use realpath() directly (which would also be thread-safe)?

That's a good question; thanks for stepping back and looking at the 
bigger picture.  If there is widespread OS support for a functionality 
then we should use it and just provide a compatibility implementation 
for those platforms lacking it.  The downside is that compat code gets 
less testing.

Seeing that readlink() is left as a stub in compat/mingw.h that only 
errors out, would the equivalent function on Windows be PathCanonicalize 
(http://msdn.microsoft.com/en-us/library/windows/desktop/bb773569%28v=vs.85%29.aspx)?

> For non-XSI-compliant platforms, we could keep the current implementation.

OK, so realpath() for Linux and the BSDs, mingw_realpath() wrapping 
PathCanonicalize() for Windows and the current code for the rest?

> Or re-implement a thread-safe version, e.g. applying resolve_symlink() from
> lockfile.c to all path components.

Thread safety sounds good.  We'd also need something like 
normalize_path_copy() but without the conversion of backslashes to 
slashes, in order to get rid of "." and ".." path components and 
something like absolute_path() that doesn't die on error, no?

> If I may bother you with the Windows point of view:
>
> There is no fchdir(), and I'm pretty sure open(".") won't work either.

On Windows, there *is* an absolute path length limit of 260 in the 
normal case and a bit more than 32000 for some functions using the \\?\ 
namespace.  So one could get away with using a constant-sized buffer for 
a "remember the place and return later" function here.

Also, _getcwd can be asked to allocate an appropriately-sized buffer for 
use, like GNU's get_current_dir_name, by specifying NULL as its first 
parameter (http://msdn.microsoft.com/en-us/library/sf98bd4y.aspx).

Not having to move around at all as mentioned above is still better, of 
course.

René