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: Eli Zaretskii <eliz at gnu dot org>
- To: Doug Evans <xdje42 at gmail dot com>
- Cc: gbenson at redhat dot com, gdb-patches at sourceware dot org
- Date: Fri, 23 Jan 2015 22:28:42 +0200
- 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>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> 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.
> 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.
> 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.