Am 18.07.2014 13:32, schrieb René Scharfe:
> 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.

I just noticed that in contrast to the POSIX realpath(), our real_path() 
doesn't require the last path component to exist. I don't know if this property 
is required by the calling code, though.

> Seeing that readlink()

You mean realpath()? We don't have a stub for that yet.

> is left as a stub in compat/mingw.h that only errors out, would the 
> equivalent function on Windows be PathCanonicalize 
> (

PathCanonicalize() doesn't return an absolute path, the realpath() equivalent 
would be GetFullPathName() (doesn't resolve symlinks) or 
GetFinalPathNameByHandle() (requires Vista, resolves symlinks, requires the 
path to exist).

>> 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?

Windows can handle forward slashes, so normalize_path_copy works just fine.

>> 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.

The current directory is pretty much the only exception to the \\?\ trick [1]. 
So a fixed buffer for getcwd() would actually be fine on Windows (although it 
would have to be 3 * PATH_MAX, as PATH_MAX wide chars will convert to at most 3 
* PATH_MAX UTF-8 chars).

However, a POSIX conformant getcwd must fail with ERANGE if the buffer is too 
small. So a better alternative would be to add a strbuf_getcwd() that works 
similar to strbuf_readlink() (i.e. resize the buffer until its large enough).

Side note: the 'hard' 260 limit for the current directory also means that as 
long as we *simulate* realpath() via chdir()/getcwd(), long paths [1] don't 
work 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 
> (

We use nedmalloc in the Windows builds, so unfortuately we cannot free memory 
allocated by MSVCRT.dll.


To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to