Re: [RFA] Add la_getstr member to language_defn

[Daniel Jacobowitz <drow@false.org>]

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