This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] zero-terminate result of target_read_alloc
> 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