[lldb-dev] [Bug 25478] New: backtick syntax is undocumented (and interacts oddly with strings)

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25478

            Bug ID: 25478
           Summary: backtick syntax is undocumented (and interacts oddly
                    with strings)
           Product: lldb
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: lldb-dev at lists.llvm.org
          Reporter: andi.m.mcclure at gmail.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

I am running lldb-340.4.110.1 (obtained via XCode 7.1.1) at the command line on
Mac OS X. I type the innocuous expression:

break set -F the_function_name -condition '0 == (int)strcmp(str1,
"IDictionary`2") && 0 == (int)strcmp(str2, "IDictionary`2")'

I get the totally baffling set of errors:

error: error: invalid suffix on literal; C++11 requires a space between literal
and identifier
error: expected ';' after expression
error: expected ';' after expression
error: use of undeclared identifier 'IDictionary'
error: 4 errors parsing expression

I find if the condition is '0 == (int)strcmp(str1, "IDictionary`2")' only, it
works fine. 

Several days pass before I figure out what is happening here. A note in the
"GDB to LLDB command map" document explains:
"NOTE: any command can inline a scalar expression result (as long as the target
is stopped) using backticks around any expression"

Once I realize this, I try placing backslashes before the backticks in my
expression:

break set -F the_function_name -condition '0 == (int)strcmp(str1,
"IDictionary\`2") && 0 == (int)strcmp(str2, "IDictionary\`2")'

Now it works.

I see three problems here.

First off, my opinion is that this is not very good behavior. I don't expect
backtick evaluation or any kind of other string mutation to silently trigger
occur *inside* of a single-quoted string (crossing between two quoted strings,
in this case!). However, I can imagine that backtick evaluation inside a string
would probably be very useful for someone somewhere, so I will assume that this
is the intentional design of the feature.

Second off, I do not think this error was well reported. The important thing,
in my case, for deciphering the error message was to understand that the
backtick substitution feature was triggering at all. The error message did not
indicate that the "error" reported was from a backtick expression.

Third and most importantly, this feature and its behavior is undocumented.
Looking at the docs on lldb.llvm.org I find the backticks are mentioned only in
the GDB->LLDB transition guide, and there only parenthetically. The transition
guide is not a good place to introduce an entire feature, and worse, the
details of how the feature work are not described (that it works even inside of
a string, that it can be neutralized with a backtick).

Expected behavior: The lldb.llvm.org documentation should fully document the
backticks in the place where expression features would normally be documented
(I recommend the "COMMAND STRUCTURE" section of the tutorial). The
documentation should explain "when" the backticks are evaluated (i.e.: before
interpreting quote characters or anything else) and any quirks or
neutralization methods the backtick has, such as the backslash escape. (The
tutorial mentions backslash-escaping now, but the only characters mentioned are
double-quote and backslash). Finally, IMO, when you are printing an error
message related to a backtick expression, the error message should actually
begin with "error in backtick expression" or "error in backslash expression".

Thanks

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20151110/c42049ef/attachment-0001.html>