From: Tom Tromey <tromey@redhat.com>
To: pmuldoon@redhat.com
Cc: gdb-patches@sourceware.org
Subject: Re: [patch] [python] Prompt substitution
Date: Tue, 19 Jul 2011 22:58:00 -0000 [thread overview]
Message-ID: <m3ipqy2dp6.fsf@fleche.redhat.com> (raw)
In-Reply-To: <m3oc0r1tjk.fsf@redhat.com> (Phil Muldoon's message of "Mon, 18 Jul 2011 16:45:51 +0100")
>>>>> "Phil" == Phil Muldoon <pmuldoon@redhat.com> writes:
Phil> +@findex gdb.get_current_prompt
Phil> +@defun get_current_prompt
Phil> +Return the current @value{GDBN} prompt as a string.
Phil> +@end defun
Is this different from gdb.parameter('prompt')?
Phil> +@findex gdb.set_current_prompt
Phil> +@defun set_current_prompt @r{[}new_prompt@r{]}
Phil> +Sets the @value{GDBN} prompt to @var{new_prompt}. @var{new_prompt}
Phil> +must be a string. This method has no return value.
Phil> +@end defun
I'm on the fence about this. It would probably be better to have a
general facility for setting parameters.
Phil> +@defop Operation {@value{GDBN}} prompt_hook [current_prompt]
Phil> +If @var{prompt_hook} exists, and is not set to @code{None},
... really if it is callable.
Phil> +The parameter @code{current_prompt} contains the current @value{GDBN}
Phil> +prompt.
If the parameter is not optional, then it should not be surrounded in []
in the @defop.
Phil> + observer_notify_before_prompt (pre_gdb_prompt);
Phil> + post_gdb_prompt = get_prompt ();
Phil> +
Phil> + /* If the observer changed the prompt, use that prompt overriding
Phil> + any new_prompt that was passed to this function. */
Phil> + if (strcmp (pre_gdb_prompt, post_gdb_prompt) != 0)
Suppose an observer sets the prompt.
Won't this free the memory pointed to by pre_gdb_prompt?
Thus making this strcmp access invalid memory?
Phil> + if (current_gdb_prompt == NULL)
Phil> + {
When can this happen?
Phil> + current_prompt = PyString_FromString (current_gdb_prompt);
Extra space after the '='.
Phil> + if ((result != Py_None) && (! PyString_Check (result)))
Too many parens.
Phil> + const char *prompt = get_prompt ();
Phil> + if (prompt)
Phil> + return PyString_FromString (prompt);
Likewise about whether this can happen.
Phil> + { "flush", (PyCFunction)gdbpy_flush, METH_VARARGS | METH_KEYWORDS,
Phil> + "Flush gdb's filtered stdout stream." },
This is already in the code and shouldn't be in this patch.
Phil> + PROMPT (0) = xstrdup (s);
Extra space.
Tom
next prev parent reply other threads:[~2011-07-19 20:55 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-18 17:09 Phil Muldoon
2011-07-19 22:58 ` Tom Tromey [this message]
2011-07-20 13:05 ` Phil Muldoon
2011-07-20 14:43 ` Tom Tromey
2011-07-21 11:15 ` Phil Muldoon
2011-08-30 19:18 ` Pedro Alves
2011-08-30 20:23 ` Phil Muldoon
2011-08-30 20:18 ` Pedro Alves
2011-08-30 20:33 ` Phil Muldoon
2011-09-02 17:41 ` Pedro Alves
2011-09-03 10:15 ` Phil Muldoon
2011-07-20 17:10 ` Eli Zaretskii
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=m3ipqy2dp6.fsf@fleche.redhat.com \
--to=tromey@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=pmuldoon@redhat.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