From: Tom Tromey <tom@tromey.com>
To: Tom Tromey <tom@tromey.com>
Cc: Philippe Waroquiers <philippe.waroquiers@skynet.be>,
gdb-patches@sourceware.org
Subject: Re: [RFA 1/2] Fix regressions for multi breakpoints command line setting/clearing
Date: Fri, 10 Aug 2018 03:05:00 -0000 [thread overview]
Message-ID: <87ftzmvs42.fsf@tromey.com> (raw)
In-Reply-To: <878t5fhxdl.fsf@tromey.com> (Tom Tromey's message of "Thu, 09 Aug 2018 18:35:18 -0600")
>>>>> "Tom" == Tom Tromey <tom@tromey.com> writes:
>>> if (repeat && *p1 == '\0')
>>> - return saved_command_line;
>>> + {
>>> + xfree (buffer_finish (cmd_line_buffer));
>>> + buffer_grow_str0 (cmd_line_buffer, saved_command_line);
>>> + cmd_line_buffer->used_size = 0;
Philippe> I was somewhat surprised by used_size being set to 0.
Philippe> I am not sure to understand in which case it is supposed to be
Philippe> set to 0 : it is set to 0 in the first few lines of handle_line_of_input
Philippe> with a comment explaining why.
Philippe> I however do not understand why it is set to the string length in
Philippe> the 'Do history expansion' case, and not to 0 : as far as I can see,
Philippe> cmd will be returned as a full line in case of expansion ?
Tom> Thanks for noticing this.
Tom> I suspect the history case (which doesn't seem to be tested...) is just
Tom> wrong and should also set the used size to 0.
I think we both misread this, because the history expansion case does:
xfree (buffer_finish (cmd_line_buffer));
cmd_line_buffer->buffer = history_value;
cmd_line_buffer->buffer_size = len + 1;
... which does not change used_size.
So, I think all the cases are behaving properly.
Tom> I'll see if I can come up with a test case here.
I'm still going to write a history expansion test, because there should
be at least one.
Philippe> So, I am wondering what kind of usage of this function
Philippe> will make the buffer bigger. Maybe worth pointing at the
Philippe> above risk then ?
Tom> I can add a comment somewhere.
Actually I don't think there is a problem here.
The growing case, I think, can only happen with continuation lines.
Otherwise the buffer is stable -- I think, provided we don't reenter the
command loop -- for the duration of the command.
Tom
next prev parent reply other threads:[~2018-08-10 3:05 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-02 21:26 RFA " Philippe Waroquiers
2018-08-02 21:26 ` [RFA 1/2] " Philippe Waroquiers
2018-08-03 18:29 ` Tom Tromey
2018-08-09 4:57 ` Tom Tromey
2018-08-09 20:20 ` Philippe Waroquiers
2018-08-10 0:35 ` Tom Tromey
2018-08-10 3:05 ` Tom Tromey [this message]
2018-08-10 3:13 ` Tom Tromey
2018-08-10 16:07 ` Tom Tromey
2018-08-11 20:38 ` Tom Tromey
2018-08-13 21:32 ` Philippe Waroquiers
2018-08-14 15:02 ` Pedro Alves
2018-08-14 18:33 ` Tom Tromey
2018-08-15 18:24 ` Tom Tromey
2018-08-16 15:34 ` Pedro Alves
2018-08-17 23:12 ` Tom Tromey
2018-08-21 18:01 ` Tom Tromey
2018-08-25 19:17 ` Philippe Waroquiers
2018-08-02 21:26 ` [RFA 2/2] Modify gdb.base/commands.exp to test multi breakpoint command setting/clearing Philippe Waroquiers
2018-08-16 15:54 ` Pedro Alves
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=87ftzmvs42.fsf@tromey.com \
--to=tom@tromey.com \
--cc=gdb-patches@sourceware.org \
--cc=philippe.waroquiers@skynet.be \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).