Re: [PATCH] zero-terminate result of target_read_alloc

["Mark Kettenis" <mark dot kettenis at xs4all dot nl>]

>  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.
>
>  I figured the same but actually reading a couple of objects and
>  managing them convinced me that Volodya's right.  Note that he's not
>  adding one to the length returned - if you want binary data, you'll get
>  binary data.  It just allows you to easily treat the result as a string
>  if you plan to treat it as a string anyway.

Sorry, but the whole distinction between strings and binary data is wrong.
Strings are binary data, including the terminating NUL.  Volodya's patch
addresses things at the wrong level.  Whatever we read using
target_read_partial() should already include the terminating NUL.

>  As you can probably guess from context, we have these bunches of XML
>  files that we read from the target and then do text processing on.
>  On the branch where I developed the XML bits for the first time, I
>  didn't think to make this change - so the very first thing I had to do
>  with the result of target_read_alloc was to allocate something one byte
>  bigger with a NUL on the end of it!

So whatever reads the XML from the target should make sure things are
NUL-terminated, and report the total length, including the terminating
NUL.

I guess you're thinking too much in terms of the remote protocol, where
you need to make the distinction between text and binary data because
you have to encode the latter to avoid problems with embedded NUL's.  But
that's really specific to the way our remote protocol works, and therefore
should be handled completely in the remote target vector code.

Mark