public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Simon Marchi <simon.marchi@polymtl.ca>
To: Tom Tromey <tom@tromey.com>,
	Simon Marchi via Gdb-patches <gdb-patches@sourceware.org>
Cc: Jan Vrany <jan.vrany@labware.com>
Subject: Re: [PATCH RESEND] gdb: remove static buffer in command_line_input
Date: Thu, 15 Dec 2022 21:49:04 -0500	[thread overview]
Message-ID: <0d76f05d-101d-584e-99bd-8d232fcee229@polymtl.ca> (raw)
In-Reply-To: <874jtwcpf0.fsf@tromey.com>



On 12/15/22 16:44, Tom Tromey wrote:
>>>>>> "Simon" == Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> writes:
> 
> Simon> [I sent this earlier today, but I don't see it in the archives.
> Simon> Resending it through a different computer / SMTP.]
> 
> I didn't see it either.
> 
> Simon> Fix that by removing the static buffer.
> 
> Wow, I've wanted to remove 'struct buffer' for a while now, this is a
> big step toward that.

Ah yeah, that's a nice side-effect indeed.

> 
> Simon> So, it started with modifying command_line_input as described above, all
> Simon> the other changes derive directly from that.
> 
> It's hard to review / understand a change like this but it seems ok to
> me, as far as I can tell.

I was eager to make more simplifications / C++ifications, but some of
them subtly broke things.  So I opted to keep things the same as much as
possible, really just change the type used to the buffer (use
std::string) and change where it was stored.

After spending a few hours debugging regressions, I am fairly confident
that I understand the code flow and that the change is correct.  I'll go
ahead and push it, to unblock Jan's patch.

> 
> Simon> One slightly shady thing is in handle_line_of_input, where we now pass a
> Simon> pointer to an std::string's internal buffer to readline's history_value
> Simon> function, which takes a `char *`.  I'm pretty sure that this function
> Simon> does not modify the input string, because I was able to change it (with
> Simon> enough massaging) to take a `const char *`.
> 
> I think sending a note to upstream readline would be good.

I forgot to mention, but I did send this message:

  https://lists.gnu.org/archive/html/bug-readline/2022-12/msg00002.html

Simon

  reply	other threads:[~2022-12-16  2:49 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-15 19:06 Simon Marchi
2022-12-15 21:44 ` Tom Tromey
2022-12-16  2:49   ` Simon Marchi [this message]
2022-12-16 13:21 ` Pedro Alves
2022-12-16 13:38   ` Simon Marchi
2022-12-16 14:11     ` 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=0d76f05d-101d-584e-99bd-8d232fcee229@polymtl.ca \
    --to=simon.marchi@polymtl.ca \
    --cc=gdb-patches@sourceware.org \
    --cc=jan.vrany@labware.com \
    --cc=tom@tromey.com \
    /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).