> On Nov 29, 2016, at 7:53 AM, Pavel Labath wrote:
>
> On 28 November 2016 at 18:06, Jim Ingham wrote:
>> backtick parsing is currently incorrect, because it parses the backtick
>> before doing arg parsing, which means it does the substitutions for “raw”
>> commands:
>>
>> (lldb) expr char *$f
On 28 November 2016 at 18:06, Jim Ingham wrote:
> backtick parsing is currently incorrect, because it parses the backtick
> before doing arg parsing, which means it does the substitutions for “raw”
> commands:
>
> (lldb) expr char *$foo = "some `1 + 2` string"
> (lldb) expr $foo
> (char *) $foo =
backtick parsing is currently incorrect, because it parses the backtick before
doing arg parsing, which means it does the substitutions for “raw” commands:
(lldb) expr char *$foo = "some `1 + 2` string"
(lldb) expr $foo
(char *) $foo = 0x00010032f100 "some 3 string"
That’s unexpected, and si
labath added a comment.
In https://reviews.llvm.org/D26883#601638, @jingham wrote:
> The outermost quote character is syntactically significant in the lldb
> command language. If you say:
>
> memory read -c `count_var` 0x123345
>
> then lldb evaluates the expression in the backticks, replacing
This revision was automatically updated to reflect the committed changes.
Closed by commit rL287597: Add the new Args / entry-access API. (authored by
zturner).
Changed prior to commit:
https://reviews.llvm.org/D26883?vs=78617&id=78796#toc
Repository:
rL LLVM
https://reviews.llvm.org/D26883
zturner added a comment.
Instead of storing the quote char, I think we could just store two
`StringRef`s. `str` and `quoted_str`, where `str =
quoted_str.trim(quote_char);`, and if there is no quote char, then they are
equal. I'd rather do that in a followup since this `ArgEntry` class has
a
jingham added a comment.
In https://reviews.llvm.org/D26883#600683, @labath wrote:
> I don't know how deep do you want this refactor to be, but there is one issue
> I would like us to consider, if only to decide it is out of scope of this
> change. I am talking about the `quote_char` thingy. Th
The reason we store the quote char, btw, is so that we can use the same
exact quoting as the user typed at command line. A general algorithm
wouldn't be able to reproduce exactly what the user typed
On Sat, Nov 19, 2016 at 9:43 AM Zachary Turner wrote:
> The main user of the c_str() is printf cal
The main user of the c_str() is printf calls. It's in the commit message :)
On Sat, Nov 19, 2016 at 7:14 AM Pavel Labath wrote:
> labath added a comment.
>
> > Assuming we do that, what interface do you think would be simpler? We
> still
> > need easy access to both a StringRef and a c_str(), si
labath added a comment.
> Assuming we do that, what interface do you think would be simpler? We still
> need easy access to both a StringRef and a c_str(), since StringRef::data
> is not guaranteed to be null terminated, so the entry thing is still nice.
I was assuming (possibly incorrectly, I
One idea might be to have the entry contain 2 StringRefs. `str` and
`quoted_str`. This way you never get access to the underlying quote char,
just the full arg, either quoted or unquoted (although doing this would
still be better done orthogonally to this patch)
On Sat, Nov 19, 2016 at 5:48 AM Zach
Assuming we do that, what interface do you think would be simpler? We still
need easy access to both a StringRef and a c_str(), since StringRef::data
is not guaranteed to be null terminated, so the entry thing is still nice.
On Sat, Nov 19, 2016 at 5:44 AM Zachary Turner wrote:
> The quote char i
The quote char is only exposed as a means to not break existing code which
depends on it (most of which, not surprisingly, is in the Args class itself.
We could try to come up with a way to kill it, but that seems like a
separate refactor (and perhaps quite difficult since different platforms
have
labath added a comment.
I don't know how deep do you want this refactor to be, but there is one issue I
would like us to consider, if only to decide it is out of scope of this change.
I am talking about the `quote_char` thingy. The main problem for me is that I
don't think it's possible to sane
zturner created this revision.
zturner added reviewers: jingham, beanz, clayborg, labath.
zturner added a subscriber: lldb-commits.
The purpose of this patch is to demonstrate my proposed new API to the `Args`
class. There are a couple of things I'm trying to demonstrate here:
1. range-based fo
15 matches
Mail list logo
