[Bug python/18779] New: collection of issues handling C strings in python

[Bug python/18779] New: collection of issues handling C strings in python

[dje at google dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18779

            Bug ID: 18779
           Summary: collection of issues handling C strings in python
           Product: gdb
           Version: unknown
            Status: NEW
          Severity: normal
          Priority: P2
         Component: python
          Assignee: unassigned at sourceware dot org
          Reporter: dje at google dot com
  Target Milestone: ---

Wanting to extract a nul-terminated string from memory given just an ELF symbol
I ran into a few warts/bugs.
This bug is to record what I find, though I may not list them all in this
initial report (I *could* file a separate report per bug, but I'm not sure how
many there will be and since they're all related I wanted to keep them
together).

Given:

const char string[] = "hello";

bug #1:

(gdb) py print
gdb.parse_and_eval("&string[0]").string(length=7,encoding="ASCII")
Traceback (most recent call last):
  File "<string>", line 1, in <module>
gdb.MemoryError: Cannot access memory at address 0x40075c
Error while executing Python code.

One can certainly argue that's an error, but not a memory access error.

bug #2:

(gdb) py print gdb.parse_and_eval("&string[0]").lazy_string()
<gdb.LazyString object at 0x7f3444f8a750>

Question: what should str(lazy_string_object) be?
If one wants the above there is "repr".
The only useful thing to me seems to be the value returned as a python string.
IOW I expected to see "hello".

feature request #1:

IWBN if one could specify that the string is nul-terminated,
which we can by specifying a length of -1, but also specify
a maximum length (for those wanting more robustness).

maybe bug #3:

I don't have a string opinion on whether this works or not,
in c or c++, just filing this for reference sake since it seems odd:

(gdb) py print gdb.parse_and_eval("&string").string()
Traceback (most recent call last):
  File "<string>", line 1, in <module>
gdb.error: Trying to read string with inappropriate type `const char (*)[6]'.
Error while executing Python code.

maybe bug #4:

If we know the array's length, how come the lazy string length is always -1?

(gdb) pt &string
type = const char (*)[6]
(gdb) py print gdb.parse_and_eval("&string[0]").lazy_string().length
-1
(gdb) py print gdb.parse_and_eval("&string").lazy_string().length
-1
(gdb) py print gdb.parse_and_eval("string").lazy_string().length
-1

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug python/18779] collection of issues handling C strings in python

[ssbssa at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=18779

Hannes Domani <ssbssa at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ssbssa at sourceware dot org

--- Comment #5 from Hannes Domani <ssbssa at sourceware dot org> ---
(In reply to dje from comment #3)
> [manually copied from 17728]
> 
> The master branch has been updated by Doug Evans <devans@sourceware.org>:
> 
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;
> h=34b433203b5f56149c27a8dfea21a921392cb158
> 
> commit 34b433203b5f56149c27a8dfea21a921392cb158
> Author: Doug Evans <dje@google.com>
> Date:   Wed Mar 15 15:35:13 2017 -0700
> 
>     Fix various python lazy string bugs.
>     
>     gdb/ChangeLog:
>     
>     	PR python/17728, python/18439, python/18779
>     	* python/py-lazy-string.c (lazy_string_object): Clarify use of LENGTH
>     	member.  Change type of TYPE member to PyObject *.  All uses updated.
>     	(stpy_convert_to_value): Fix handling of TYPE_CODE_PTR.
>     	(gdbpy_create_lazy_string_object): Flag bad length values.
>     	Handle TYPE_CODE_ARRAY with possibly different user-provided length.
>     	Handle typedefs in incoming type.
>     	(stpy_lazy_string_elt_type): New function.
>     	(gdbpy_extract_lazy_string): Call it.
>     	* python/py-value.c (valpy_lazy_string): Flag bad length values.
>     	Fix handling of TYPE_CODE_PTR.  Handle TYPE_CODE_ARRAY.  Handle
>     	typedefs in incoming type.
>     
>     gdb/testsuite/ChangeLog:
>     
>     	PR python/17728, python/18439, python/18779
>     	* gdb.python/py-value.c (main) Delete locals sptr, sn.
>     	* gdb.python/py-lazy-string.c (pointer): New typedef.
>     	(main): New locals ptr, array, typedef_ptr.
>     	* gdb.python/py-value.exp: Move lazy string tests to ...
>     	* gdb.python/py-lazy-string.exp: ... here.  Add more tests for pointer,
>     	array, typedef lazy strings.

Did this commit fix all problems reported here?
If not, what's missing?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug python/18779] collection of issues handling C strings in python

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=18779

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #6 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to Hannes Domani from comment #5)

> Did this commit fix all problems reported here?
> If not, what's missing?

str() of a lazy string still seems wrong according to the wish-list
in this bug:

>>> str(gdb.parse_and_eval('&string[0]').lazy_string())
'<gdb.LazyString object at 0x7f7605d7f180>'

It seems reasonable to me to want this to de-lazy a string.

-- 
You are receiving this mail because:
You are on the CC list for the bug.