This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 3/3 v2] Implement completion limiting
- From: Doug Evans <xdje42 at gmail dot com>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: Gary Benson <gbenson at redhat dot com>, "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Fri, 23 Jan 2015 16:32:29 -0800
- Subject: Re: [PATCH 3/3 v2] Implement completion limiting
- Authentication-results: sourceware.org; auth=none
- References: <1417094168-25868-1-git-send-email-gbenson at redhat dot com> <1417094168-25868-4-git-send-email-gbenson at redhat dot com> <m3y4ql4psf dot fsf at sspiff dot org> <20141210122233 dot GA7299 at blade dot nx> <m3mw6v4gm8 dot fsf at sspiff dot org> <21671 dot 20308 dot 262958 dot 475080 at ruffy2 dot mtv dot corp dot google dot com> <20150107084255 dot GA17867 at blade dot nx> <21680 dot 36641 dot 315766 dot 209208 at ruffy2 dot mtv dot corp dot google dot com> <83a91r6lbd dot fsf at gnu dot org> <CADPb22TOJ2uqQKyzEpQyCrm92-ARexduUk0b2rDqJwQvdU1uLw at mail dot gmail dot com> <20150115153930 dot GA14900 at blade dot nx> <m3vbjy9iqr dot fsf at sspiff dot org> <83h9vhu7k8 dot fsf at gnu dot org> <CAP9bCMQ_tpWGO3RvPuXkdEi4N4R-GWewrUFhktmeKp7+iPG5yA at mail dot gmail dot com> <83zj99sbgk dot fsf at gnu dot org> <CAP9bCMTX+yZZ=QWv=4TbG72quo6WyG8vjfn9VFV5LcJ7D4zS5w at mail dot gmail dot com> <83wq4ds0lh dot fsf at gnu dot org>
On Fri, Jan 23, 2015 at 12:28 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Fri, 23 Jan 2015 08:56:59 -0800
>> From: Doug Evans <xdje42@gmail.com>
>> Cc: Gary Benson <gbenson@redhat.com>,
>> "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
>>
>> How often will there be exactly N?
>
> About the same frequency as there will be exactly N-1, I guess.
My point is, given any particular value I set for
"set max-completions N", what's the probability
that exactly that N completions will be found?
Rather low I expect.
>> And in that particular and massively rare case,
>> once gdb has found N, how much extra work will
>> be performed searching the entire executable
>> and all its shared libraries just to verify there are
>> in fact no more completions?
>> [because that's what has to happen if
>> we're to avoid printing *any* message]
>>
>> The user waits 5 minutes for the entire list and
>> gets her 200 completions, and wonders
>> why it took so long. Then she digs a bit
>> deeper and finds out they were found
>> in the first 5 seconds. Ugh.
>
> 200 is just a random number. It's not magic in any way. So you
> could have 199 completions found in the first 5 sec, followed by 5
> minutes of waiting for the 200th which is never found. Ugh.
>
> There's no way around this issue.
But if I, as a user, do "set max-completions 199"
and then find out gdb is looking for 200 completions
I would be disappointed. I might file a bug report even.
If I do "set max-completions N" I expect gdb to stop looking
when it gets to N.
>> I don't see the benefit of going to the trouble
>> of avoiding printing any message when there are
>> exactly N completions.
>
> That's fine, but then the option's name and its documentation should
> be changed to reflect this. They currently support what I thought
> user will get, not what you describe above.
The option name and documentation is fine.
If I do "set max-completions 42" I expect
gdb to stop looking when it finds 42 completions.
It's a rather straightforward interpretation of the option's
name IMO.