Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "André Pönitz" <andre.poenitz@nokia.com>
To: gdb-patches@sourceware.org
Subject: Re: [RFA] 12843
Date: Mon, 29 Aug 2011 07:19:00 -0000	[thread overview]
Message-ID: <201108290920.40589.andre.poenitz@nokia.com> (raw)
In-Reply-To: <m3hb54rnyh.fsf@fleche.redhat.com>

On Friday 26 August 2011 21:07:34 ext Tom Tromey wrote:
> Keith> I can play with that a little further. I'll also take the time to add
> Keith> a bunch of tests to highlight some of the problems. There is an open
> Keith> PR about this, to. In general the use of ':' or "::" in filenames is
> Keith> really bad for linespecs.
> 
> My view is that, aside from the drive-letter case, we should require
> funny file names to be quoted.  That is:
> 
> Valid:    break 'file with spaces.c':73
> Invalid:  break file with spaces.c:73
> 
> Valid:    break 'file:with:colons.c':73
> Invalid:  break file:with:colons.c:73
> 
> Valid either way:
>           break c:/file.c:73
>           break 'c:/file.c':73
> 
> I am not sure how to handle file names with quotes; IIUC typical
> escaping syntax won't work because it is already used in DOS-style file
> names.  This matters since I think MI clients already have to play funny
> games here :-(

Indeed. Something like

 25-break-insert -f "\"some thing.cpp\":794"

tends to work. I found it non-obvious in the beginning...

> (I'd like -break-insert to avoid linespecs completely, which would be a
> big improvement IMO, ...

From an MI client's point of view, passing all location information as 
a single argument is neither wanted nor needed.

 25-break-insert --file "some thing.cpp" --line 794

or even require everything to be quoted as in

 25-break-insert  --file "some thing.cpp" --line "794"

would be easier to handle than what's there now.

> ... but of course we still have to worry about compatibility.)

Just using new flags for the parameters should do the trick in this case.

In general, in the past, differences between different versions of gdb have
been large enough to require modifications in consumer code anyway (both
to take advantage of new features, and to handle incompatibilities in input
syntax), so requiring 100% "feature" compatibility _just for the sake of it_ is
unlikely to be helpful. At least I would prefer a syntax with simple, uniform
quoting rules over ad-hoc solutions tied to a specific OS or file system.

> [...]
> I think adopting these rules will make some of my ambiguous linespec
> changes simpler. 

I wonder whether it would be possible to just leave the current syntax
unchanged, and introduce a new, better behaved syntax and use some
global setting for toggling between them. So everybody concerned about
compatibility would not notice a change, and the others would put 

  'set breakpoint syntax 2011'  [or whatever]

in their .gdbinit and could use the new way.

Andre'


  parent reply	other threads:[~2011-08-29  7:19 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-25 21:59 Keith Seitz
2011-08-26 18:23 ` Tom Tromey
2011-08-26 18:46   ` Keith Seitz
2011-08-26 19:07     ` Tom Tromey
2011-08-27  8:45       ` Eli Zaretskii
2011-08-27 13:17         ` asmwarrior
2011-08-29 19:18         ` Tom Tromey
2011-08-29  7:19       ` André Pönitz [this message]
2011-08-29 10:13         ` Pedro Alves
2011-08-29 12:06           ` Matt Rice
2011-08-29 12:15           ` André Pönitz
2011-08-29 13:53             ` Pedro Alves
2011-08-29 19:21             ` Jan Kratochvil
2011-08-30  8:19               ` André Pönitz
2011-08-30  9:21                 ` Jan Kratochvil
2011-08-30 15:02                 ` Tom Tromey
2011-08-30 16:34                   ` André Pönitz
2011-08-30 17:21                     ` Tom Tromey
2011-08-31  8:54                       ` André Pönitz
2011-08-29 19:46         ` Tom Tromey
2011-08-29 21:13           ` Keith Seitz
2011-08-30  2:35             ` Daniel Jacobowitz
2011-08-30 15:00             ` Tom Tromey
2011-08-30 17:24               ` Tom Tromey
2011-08-31 18:17   ` Keith Seitz
2011-08-31 18:23     ` Jan Kratochvil
2011-08-31 18:52     ` Tom Tromey
2011-09-02 16:04     ` asmwarrior

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201108290920.40589.andre.poenitz@nokia.com \
    --to=andre.poenitz@nokia.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox