public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
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

  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).