[llvm-commits] [llvm] r136459 - /llvm/trunk/lib/Support/Unix/Path.inc

[Nick Lewycky]

On 29 July 2011 13:26, Chris Lattner <clattner at apple.com> wrote:

>
> On Jul 29, 2011, at 1:18 PM, Nick Lewycky wrote:
>
> On 29 July 2011 11:57, Chris Lattner <clattner at apple.com> wrote:
>
>>
>> On Jul 29, 2011, at 11:30 AM, Nick Lewycky wrote:
>>
>> > The only other effect of this change is that the static analysis will
>>> now
>>> > respect $PWD when reporting the directory of the files in its HTML
>>> output. I
>>> > think that's fine.
>>>
>>> Uhm, this *really* doesn't seem like the right thing to do.  This should
>>> go into a client of this API that cares, not being in such a low level API.
>>>
>>
>> Reverted in r136477. I honestly don't see how it's any more or less
>> correct than using getcwd, since $PWD is the current directory per
>> definition.
>>
>>
>> If it's the current directory by definition, why doesn't getcwd return it?
>>
>
> POSIX specs that the value returned by getcwd may not contain symbolic
> links. PWD may contain symbolic links because of how it's required to be set
> by "cd". In either case it needs to be the current directory, but they can
> be different strings.
>
>
> What if clang is not being run by a shell?  PWD is a shell thing, not a
> unix syscall thing.
>

Mm, you're right. I misremembered PWD as being a required environment
variable across all process invocations, but it's only defined in the shell
execution environment, which applies only to things run by the shell. The
answer is that if PWD were unset it would fall back to getcwd. Of course,
PWD could also be just plain wrong if not invoked by a shell.

I didn't really want to have two get current directory methods in Support,
and I don't think I want to hard-code "PWD" in clang. Does
getShellCurrentDirectory in Support sound reasonable?

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20110729/7b63bd89/attachment.html>