[RFA] Add la_getstr member to language_defn
Daniel Jacobowitz
drow@false.org
Mon Nov 24 13:32:00 GMT 2008
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
More information about the Gdb-patches
mailing list