[llvm] r297483 - Add llvm::sys::fs::real_path.

[Pavel Labath via llvm-commits]

On 9 January 2018 at 02:21, Davide Italiano <davide at freebsd.org> wrote:
> On Fri, Mar 10, 2017 at 9:39 AM, Zachary Turner via llvm-commits
> <llvm-commits at lists.llvm.org> wrote:
>> Author: zturner
>> Date: Fri Mar 10 11:39:21 2017
>> New Revision: 297483
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=297483&view=rev
>> Log:
>> Add llvm::sys::fs::real_path.
>>
>> LLVM already has real_path like functionality, but it is
>> cumbersome to use and involves clean up after (e.g. you have
>> to call openFileForRead, then close the resulting FD).
>>
>> Furthermore, on Windows it doesn't work for directories since
>> opening a directory and opening a file require slightly
>> different flags.
>>
>> So I add a simple function `real_path` which works for all
>> paths on all platforms and has a simple to use interface.
>>
>> In doing so, I add the ability to opt in to resolving tilde
>> expressions (e.g. ~/foo), which are normally handled by
>> the shell.
>>
>>
>
> Apologies for thread necromancy, but the only consumer of this is
> subtly broken in some cases :( (i.e. lldb)
> In particular, if you have a directory that you can stat() but has no
> read permissions, real_path() will fail (note that POSIX realpath()
> doesn't).
>
> I wonder why on UNIX we don't just have this as a wrapper to the POSIX
> realpath?

I don't think there's any reason we could not do that. It was probably
done this way because it was easy to reuse existing primitives for
that (and the realpath logic in openFileForRead seems to have been
heavily optimised for speed).

Right now, I don't think any existing real_path user cares too much
about speed, so we could probably just make it a simple realpath(3)
wrapper. If we later find that's too slow, we could try to make this
more fancy by trying to open the file first, and only fall back to
real_path if the open fails.