Re: [RFA_v4 1/8] Add helper functions parse_flags and parse_flags_qcs

[Tom Tromey <tom@tromey.com>]

>>>>> "Tom" == Tom Tromey <tom@tromey.com> writes:

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

Tom> Yeah, my approach has been to require the callers of
Tom> handle_line_of_input to handle the storage, so nothing relies on
Tom> saved_command_line surviving across reentrant calls.

The bug in my patch turns out to be this line in top.c:

      if (repeat_arguments != NULL && cmd_start == saved_command_line)

... which relies on handle_line_of_input returning saved_command_line
exactly rather than a copy.

Fixing this in a good way will require passing a bit more information
through the maze of functions.  This part of gdb sure seems complicated
for what it does.

A less principled way to fix this would be to stuff another global in
there somewhere, to indicate that the current command is a repeat.  This
is "safe" in that nearly nothing ought to check the global.  However, I
think I'd rather try not to introduce more globals, at least unless I
get too annoyed.

Tom