From: Tom Tromey <tromey@redhat.com>
To: Phil Muldoon <pmuldoon@redhat.com>
Cc: gdb-patches ml <gdb-patches@sourceware.org>
Subject: Re: [patch][python] Implement Python lazy strings (PR 10705)
Date: Mon, 11 Jan 2010 21:08:00 -0000 [thread overview]
Message-ID: <m3y6k4nydr.fsf@fleche.redhat.com> (raw)
In-Reply-To: <4B4746A7.90309@redhat.com> (Phil Muldoon's message of "Fri, 08 Jan 2010 14:52:23 +0000")
>>>>> "Phil" == Phil Muldoon <pmuldoon@redhat.com> writes:
Phil> Index: gdb/varobj.c
[...]
Phil> + if (is_lazy_string (output))
Phil> + thevalue = extract_lazy_string (output, &type,
Phil> + &len, &encoding);
Phil> + else
Phil> {
Phil> - char *s = PyString_AsString (py_str);
Phil> - len = PyString_Size (py_str);
Phil> - thevalue = xmemdup (s, len + 1, len + 1);
Phil> - Py_DECREF (py_str);
Phil> + PyObject *py_str
Phil> + = python_string_to_target_python_string (output);
Phil> + if (py_str)
Phil> + {
Phil> + char *s = PyString_AsString (py_str);
Phil> + len = PyString_Size (py_str);
Phil> + thevalue = xmemdup (s, len + 1, len + 1);
Phil> + type = builtin_type (gdbarch)->builtin_char;
Phil> + Py_DECREF (py_str);
Phil> + }
Phil> }
Phil> Py_DECREF (output);
Phil> }
Phil> if (thevalue && !string_print)
Phil> {
Phil> do_cleanups (back_to);
Phil> + xfree (encoding);
Phil> return thevalue;
This is wrong in the lazy string case, because you are returning raw
bytes, but the user expects them to be interpreted according to the
encoding.
We discussed this on irc and I thought the result was that we agreed
that in this case we would pretend that a "string" hint was given.
One way to do this would be to set "string_print = 1" in the lazy case.
The documentation for the "string" hint should mention this.
Phil> +PyObject *
Phil> +gdbpy_create_lazy_string_object (CORE_ADDR address, long length,
Phil> + const char *encoding, struct type *type)
Phil> +{
[...]
Phil> + if (!str_obj)
Phil> + return NULL;
Indentation looks wrong on the second line.
Phil> +/* Determine whether the printer object pointed to by OBJ is a
Phil> + Python lazy string. */
Phil> +int
Phil> +is_lazy_string (PyObject *result)
Phil> +{
Phil> + return PyObject_TypeCheck (result, &lazy_string_object_type);
Phil> +}
Why here and not in py-lazy-string.c?
Then lazy_string_object_type could be static.
Phil> +/* Extract and return the actual string from the lazy string object
Phil> + STRING. Additionally, the string type is written to *STR_TYPE, the
Phil> + string length is written to *LENGTH, and the string encoding is
Phil> + written to *ENCODING. On error, NULL is returned. The caller is
Phil> + responsible for freeing the returned buffer. */
Phil> +gdb_byte *
Phil> +extract_lazy_string (PyObject *string, struct type **str_type,
Phil> + long *length, char **encoding)
Likewise.
Phil> + output = convert_value_from_python (string);
Why do we need to do this?
Can't we just get the address directly?
Phil> + TRY_CATCH (except, RETURN_MASK_ALL)
Phil> + {
Phil> +
Extra blank line.
Phil> + if (except.reason < 0)
Phil> + {
Phil> +
Likewise.
Phil> +}
Phil> +
Phil> +
Phil> +
Likewise.
Phil> + int is_lazy = 0;
Phil> +
Phil> + is_lazy = is_lazy_string (py_str);
There's no need to initialize is_lazy to 0 if you then immediately
assign to it.
Phil> + gdb_byte *output = NULL;
Phil> + struct type *type;
Phil> + long length;
Phil> + char *encoding = NULL;
Phil> +
Phil> + if (is_lazy_string (py_v))
Phil> + {
Phil> + output = extract_lazy_string (py_v, &type, &length, &encoding);
Phil> + if (!output)
Phil> + gdbpy_print_stack ();
Phil> + LA_PRINT_STRING (stream, type, output, length, encoding,
Phil> + 0, options);
Phil> + xfree (encoding);
Phil> + xfree (output);
Variables like 'encoding' that are only used in one branch of the if
should just be declared in that branch.
Tom
next prev parent reply other threads:[~2010-01-11 21:08 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-08 14:52 Phil Muldoon
2010-01-08 16:25 ` Eli Zaretskii
2010-01-11 15:40 ` Phil Muldoon
2010-01-11 19:10 ` Eli Zaretskii
2010-01-11 21:08 ` Tom Tromey [this message]
2010-01-11 21:30 ` Phil Muldoon
2010-01-11 21:40 ` Phil Muldoon
2010-01-12 17:02 ` Tom Tromey
2010-01-13 14:49 ` Phil Muldoon
2010-01-13 18:13 ` Tom Tromey
2010-01-13 20:23 ` Phil Muldoon
2010-01-13 20:33 ` Tom Tromey
2010-01-14 21:24 ` Phil Muldoon
2010-01-13 18:24 ` 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=m3y6k4nydr.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