This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA_v4 1/8] Add helper functions parse_flags and parse_flags_qcs
- From: Tom Tromey <tom at tromey dot com>
- To: Philippe Waroquiers <philippe dot waroquiers at skynet dot be>
- Cc: Tom Tromey <tom at tromey dot com>, Joel Brobecker <brobecker at adacore dot com>, gdb-patches at sourceware dot org
- Date: Tue, 31 Jul 2018 22:04:08 -0600
- Subject: Re: [RFA_v4 1/8] Add helper functions parse_flags and parse_flags_qcs
- References: <20180710213926.32240-1-philippe.waroquiers@skynet.be> <20180710213926.32240-2-philippe.waroquiers@skynet.be> <20180730201556.GA19069@adacore.com> <87pnz4o2iu.fsf@tromey.com> <20180731135242.GA3186@adacore.com> <87va8v4dmy.fsf@tromey.com> <1533071582.1467.21.camel@skynet.be>
>>>>> "Philippe" == Philippe Waroquiers <philippe.waroquiers@skynet.be> writes:
Philippe> I am wondering if the correct solution would not be to avoid
Philippe> having input lines memory being managed 'manually' like it is now,
Philippe> as having the 'input const char* arg' disappearing 'under the carpet'
Philippe> is quite tricky, and we might have other places where a previous
Philippe> line of input must be kept alive, while new lines of input have
Philippe> to be read.
Yeah, my approach has been to require the callers of
handle_line_of_input to handle the storage, so nothing relies on
saved_command_line surviving across reentrant calls.
Thanks for pointing out that other regression. I don't think I was
aware of that one.
Tom