This is the mail archive of the 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] 12843

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.


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