chapuni added a subscriber: chapuni.
chapuni added a comment.
Excuse me, I have reverted it in r263636.
Comment at: lib/Frontend/ModuleDependencyCollector.cpp:65
@@ +64,3 @@
+static bool real_path(StringRef SrcPath, SmallVectorImpl &RealPath) {
+#ifdef HAVE_REALPATH
+ char Cano
Thanks!
On Wed, Mar 16, 2016 at 5:35 AM, NAKAMURA Takumi wrote:
> chapuni added a subscriber: chapuni.
> chapuni added a comment.
>
> Excuse me, I have reverted it in r263636.
>
>
>
> Comment at: lib/Frontend/ModuleDependencyCollector.cpp:65
> @@ +64,3 @@
> +static bool real_path
bruno closed this revision.
bruno added a comment.
Committed r261551
http://reviews.llvm.org/D17104
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
benlangmuir accepted this revision.
benlangmuir added a comment.
This revision is now accepted and ready to land.
LGTM if you fix 256->PATH_MAX.
Comment at: lib/Frontend/ModuleDependencyCollector.cpp:66
@@ +65,3 @@
+#ifdef HAVE_REALPATH
+ char CanonicalPath[256];
+
bruno updated this revision to Diff 48397.
bruno added a comment.
Updated the patch, with the following changes:
Handle ".", ".." and "./" with trailing slashes while collecting files
to be dumped into the vfs overlay directory.
Include the support for symlinks into components. Given the
benlangmuir added a comment.
Okay, let's go with the two-path solution. Thanks!
http://reviews.llvm.org/D17104
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
bruno added a comment.
> I'm not sure I understand how the 2nd path would cover the realpath case. It
> is just an entry for the realpath itself; that doesn't help if the client
> looks up "/install-dir/lib/clang/3.8.0" directly (not just from removing dots
> from bin/..).
What I was suggest
benlangmuir added a comment.
> Given the two-path solution, another thing we could do in the first path, is
> to default to the remove_dots() version for the source, i.e.
> "/install-dir/lib/clang/3.8.0/include" instead of
> "/install-dir/bin/../lib/clang/3.8.0/include". The path after remove_d
bruno added a comment.
> Your two-path solution seems like it's on the right track but I don't like
> that it brings us back to having ".." in the source path.
Given the two-path solution, another thing we could do in the first path, is to
default to the remove_dots() version for the source, i
benlangmuir added a comment.
> Now, we try to use the new YAML file + cache from a new clang invocation.
> When the FileManager requests status in (2) for the path
> "/install-dir/bin/../lib/clang/3.8.0/include/altivec.h" neither
> "remove_dots()" nor "realpath()" would be able to resolve it to
bruno added a comment.
> I don't think this is the right approach. If we don't canonicalize the
> source path then:
>
> - looking up the path *without* the .. won't work, which means anything that
> looks up a realpath will fail
If we canonicalize, then it needs to be done in two places:
benlangmuir added a comment.
I don't think this is the right approach. If we don't canonicalize the source
path then:
- looking up the path *without* the .. won't work, which means anything that
looks up a realpath will fail
- directory iteration won't combine entries from foo/bar/.. and foo/
bruno added a comment.
In http://reviews.llvm.org/D17104#349141, @benlangmuir wrote:
> Please clarify what you mean here:
>
> > The rationale is that if source and destination paths in the YAML file
> > contain ".." this is enough
>
> > for the file manager to retrieve the right file, meaning t
benlangmuir added a comment.
Please clarify what you mean here:
> The rationale is that if source and destination paths in the YAML file
> contain ".." this is enough
> for the file manager to retrieve the right file, meaning that it doesn't
> matter how we write it
> since the FileManager
bruno created this revision.
bruno added reviewers: bogner, benlangmuir.
bruno added subscribers: cfe-commits, dexonsmith.
This patch removes the path traversals check/assertion related with the
presence of ".." in paths.
The rationale is that if source and destination paths in the YAML file con
15 matches
Mail list logo
