gdb-patches Digest 17 Oct 2002 18:15:14 -0000 Issue 1383

[Jim Ingham]

I think it is too strong to say the behavior "was a mistake"...  If you 
don't allow the spaces then pretty much every ObjC symbol you have to 
break on will have to be quoted.  The mistake, if there was any, was 
not to tell our users that gdb is too lame to handle ObjC method names 
without quoting before they got it into their heads (and fingers) that 
not having to put the quotes in every time was REALLY NICE...

I very seriously doubt we will be able to get folks here to change 
their ways.  In fact, I am leaving it to Klee to "do some research 
among our Objective-C developers..." because if I suggested this it, 
they could come over to my office en masse and kill me, whereas Klee, 
being a remotie, just has to make sure not to open packages without 
return addresses, and he will be okay...

The main trouble with the patch is just that it means a little surgery 
in decode_line_1, nobody's favorite part of gdb!  Also, the changes 
were much more trouble for us than they will be for you.  Local patches 
to decode_line_1 are actually little gravitational wells of evil which 
suck in any change anywhere in the function and turn them into new & 
mysterious bugs.  These we have to sort out every time we do a merge.  
When the code is actually in the version that everyone is working on, 
maintenance will be much easier.

Finally, being able to just type an ObjC method call straight without 
having to go through the little "*%$*, forgot the quotes, up-arrow, 
insert quotes, return" dance is worth the effort for the standard 
version of gdb.  I think you should take this patch.


Jim

On Thursday, October 17, 2002, at 11:15  AM, 
gdb-patches-digest-help@sources.redhat.com wrote:

> Klee Dienes <klee@apple.com> writes:
>> In the Apple code, we use skip_quoted to allow for the possibility of
>> spaces in Objective-C function names.
>>
>> I'm actually coming to think that allowing people to break on unquoted
>> Objective-C methods was a mistake: it's caused us no end of trouble
>> trying to shoehorn decode_line_1() into handling every possible
>> edge-case.  I'm not sure how practical it is for us to remove it at
>> this point, though --- we'd have to do some research among our
>> Objective-C developers to find out how important a feature it is to
>> them, I think.
>
> So, the original patch posted is preparation for a behavior which you
> now suspect was a mistake, and which has caused you no end of trouble?
> (Or do I have the sense of what you were saying reversed?)  You can
> forgive me if hearing that makes me a bit hesitant to approve the
> patch, right?  :)
>
--
Jim Ingham                                   jingham@apple.com
Developer Tools
Apple Computer