This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA 7/9] Explicit locations v2 - CLI for explicit locations


On 05/08/2014 05:48 PM, Matt Rice wrote:
Just curious if we need this quote handling in explicit linespec's

Good question! I did this so long ago, I'm not 100% certain /why/ I chose to include quoting, but I can have a guess...

UI consistency. It is allowed in linespecs, largely -- but not entirely -- to work around (old) parser problems. Users are, sadly, quite used to quoting things. In order to maintain some sort of parallelism, I *think* that I added the ability to quote stuff, but it is not necessary (see below).

I thought (though i'm not terribly familiar with c++ linespecs)
that the quotes were for operator+, clashing with foo+offset
and 'something::foo' clashing with file:line stuff,

With the "new" linespec parser, I've tried to minimize the need to quote anything. Alas, as you point out, the need still arises.

One of the tests that I have added for dprintfs seems to indicate that I had similar concerns about permissive quoting:

(gdb) dprintf -func A::operator,,"hello\n"

Believe it or not, that actually does do what it is supposed to do. [Ok, maybe I am the only one surprised to (re)discover that.]

where it isn't obvious to me the need for it arises when using
explicit locations.
I suppose break -source '/path with spaces/foo.c' -line +42

I tried this on my working copy:

(gdb)  b -source /dir with spaces/file with spaces.c -line 3
No source file named /dir with spaces/file with spaces.c.
Make breakpoint pending on future shared library load? (y or [n]) n

So it seems I already had something in mind to handle spaces in a relatively sane way. [Not that there aren't any lurking bugs -- I'll be the first to admit I am seldom capable of writing bug-free code with a patch this large.]

my main curiosity here is for languages which allow the ' character,
particularly the ML family's usage of type variables[1]. to
discriminate polymorphic functions of the variety break -function
foo('a) vs break -function foo(string).

The parser seems to already permit this syntax, but again, I'm sure there are latent bugs in there somewhere:

(gdb) b -func foo('a)
Function "foo('a)" not defined.
Make breakpoint pending on future shared library load? (y or [n]) n

So, in the end, it certainly seems that we could whack this quoting stuff altogether if it was so desired. Other than the parallelism `argument' that I think I used to justify this to myself when I originally wrote it, there isn't really a compelling reason to keep it. At least, not that I know of/remember right now.

Keith


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]