I don't think that's correct. I think directory should be tmp and filename
should be null in that case.
It's interesting that this happens when resolve == false, I would have
thought most differences to arise when resolve == true.
It's too bad we didn't have test/functionalities/paths back then. It's
hard to know what's breaking and what we need to verify each time we make a
change.
Whatever the decision is, I think we should prioritize building up a
comprehensive set of tests that hit all the edge cases. I can volunteer to
go in and add a bunch of windows specific tests and edge cases, if someone
else will do the linux ones.
This is at least the 4th time in recent memory that FileSpec has bitten us,
so it's probably woth setting aside some time and building up a bunch of
test cases from scratch.
On Wed, Mar 11, 2015 at 2:35 PM Greg Clayton <gclay...@apple.com> wrote:
> FileSpec was changed a while back and currently if we make call like:
>
> FileSpec tmp("/tmp", false);
>
> will result in a m_filename that contains "." and a m_directory that
> contains "/tmp". Is this expected?
>
> If so we should to change:
>
> void
> FileSpec::AppendPathComponent (const char *new_path);
>
> to not make the path be "/tmp/./<new_path>"...
>
> Greg
> _______________________________________________
> lldb-dev mailing list
> lldb-dev@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
