Re: [PATCH] zero-terminate result of target_read_alloc

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> Date: Mon, 24 Jul 2006 00:09:37 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> On Tue, Jul 18, 2006 at 01:25:22PM +0200, Mark Kettenis wrote:
> > >
> > >  This patch makes result of target_read_alloc zero-terminated.
> > >  The point is that often the object is not allowed to contain embedded
> > >  zeros,
> > >  and working with zero-terminated strings is much easier.
> > >
> > >  OK?
> > 
> > This is wrong.  Either the terminating nul is part of the object you're
> > reading or it is not.  GDB shouldn't at its own.
> 
> Hi Mark,
> 
> There was some followup discussion on this, and we didn't hear back
> from you.  My own explanation of the current behavior is that this is
> an interface for reading binary data from the target, much like reading
> it from files, so it shouldn't be NUL terminated - but the client may
> expect the data to not contain embedded NULs and we have the
> opportunity to be helpful here, so we should be helpful.

Sorry, yes.  I didn't manage to reply yet.  I don't find the arguments
very convincing.  You try to justify the interface by giving examples
of interfaces that are very different from target_read_alloc() (and
much more similar to target_read()).

> Do you find that convincing?  If not, would you be happier if there
> were two functions to do this, one which added the NUL and one which
> did not?  I'm thinking target_read_alloc and target_read_stralloc,
> indicating that we allocate the result as if it were a string.

That seems a reasonably compromise to me.  It makes things much more
explicit.  I think you should go one step further, and make
target_read_stralloc() return "char *" instead of "LONGEST" (and do
away with the "gdb_byte **" argument).  That'd solve the issue whether
the length returned includes the terminating NUL or not.  The function
would return a NULL pointer upon failure and an empty string on (the
equivalent of) EOF.

Mark