This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] Add la_getstr member to language_defn
- From: Daniel Jacobowitz <drow at false dot org>
- To: Thiago Jung Bauermann <bauerman at br dot ibm dot com>
- Cc: gdb-patches ml <gdb-patches at sourceware dot org>
- Date: Sun, 23 Nov 2008 11:10:13 -0500
- Subject: Re: [RFA] Add la_getstr member to language_defn
- References: <1227417278.28256.183.camel@localhost.localdomain>
On Sun, Nov 23, 2008 at 03:14:37AM -0200, Thiago Jung Bauermann wrote:
> One improvement which is easy to make but I left for later (this patch
> is big enough already) is to nuke target_read_string and make its
> callers use read_string instead (the former implements just a subset of
> what the latter provides). It would be a simple modification, but would
> affect code specific to targets to which I don't have access to
> (target_read_string is almost exclusively used in solib-*.c). I can work
> on a subsequent patch to do that if you think it's safe enough to not
> require my testing on all affected targets.
What's the difference between them?
> +/* Obtain a C string from the inferior, storing it in a newly allocated
> + buffer in BUFFER, which should be freed by the caller. If VALUE is an
> + array with known length, the function will copy all of its contents to
> + the buffer. If the length is not known, read until a null byte is found.
> + LENGTH will contain the size of the string (not counting the NULL
> + character).
This is the right behavior for gdb's "print VAR". But I'm not sure
it's the right behavior for a method named la_getstr - in fact I think
it isn't. Suppose (to pick a random example with no relation to
anything - no, wait, it's from the Linux kernel...):
struct task_struct
{
volatile long state;
...
char comm[16];
...
};
If I ask for the contents of the array, I should get sixteen bytes.
But if I ask for a string I ought to get, in my opinion, up to sixteen
bytes. Characters up to but not including the first zero, or sixteen
at most. A ps implementation which prints "comm\0er command" is not
very helpful :-)
BTW, it's not a NULL character; it's NUL, the null character. NULL
in uppercase is the pointer.
--
Daniel Jacobowitz
CodeSourcery