[Lldb-commits] [PATCH] [2/2] Fix Path support on Windows
zturner at google.com
Wed Jul 30 23:26:20 PDT 2014
Yea. That would just be the programmers fault for doing the wrong thing.
Just to elaborate on the decision for passing it in to the constructor, the
reason is because I thought it would be useful (even if not now, perhaps in
the future) to manipulate paths of one platform on another platform.
Imagine you're on Linux, for example, and remote debugging a Windows
process. So, on Linux, you create a target with the path
D:\foo\target.exe, because this path refers to a location on the remote
machine. It's possible that the host may never need to store a path like
this in a FileSpec, and it could just pass it straight to the remote
machine. But it seems hard to say with confidence that we would NEVER to
create a FileSpec on machine A referring to a path on machine B.
On Wed, Jul 30, 2014 at 7:18 PM, <jingham at apple.com> wrote:
> > On Jul 30, 2014, at 6:50 PM, Greg Clayton <gclayton at apple.com> wrote:
> > Why does the user ever want to specify the PathSyntax? Shouldn't it just
> be something that can be queried and be set automagically?
> > What if I did:
> > FileSpec f("C:\Users\me\foo.txt", false, ePathSyntaxPosix);
> > If I set it incorrectly, seems like it might "do the wrong thing" in
> some calls. It might be nice to use a C++11 typed bitfield to store the
> PathSyntax to keep the size of the FileSpec class down to as small as
> possible (uint8_t).
> I actually think this is okay. That path could either be a Unix relative
> path, or a Windows absolute path. FileSpec couldn't know which one it was,
> so if it matters (like if you planned to append to it) you would need to be
> able to tell the FileSpec constructor what you were making.
> lldb-commits mailing list
> lldb-commits at cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-commits