Re: [PATCH] zero-terminate result of target_read_alloc

[Vladimir Prus <vladimir at codesourcery dot com>]

On Tuesday 18 July 2006 17:39, Daniel Jacobowitz wrote:

> Here's a better way to think about the patch, I think.  Consider the
> result of target_read_alloc to be the contents of a disk file.  It
> might be an ELF executable or a text README file.  The caller knows
> which sort of data it is, and will process it appropriately, but
> target_read_alloc is just fread in this model.  It doesn't know whether
> the contents are text or binary.  If they are text, why should they
> include a terminating NUL in the disk file?
>
> So with this change, the interface is friendly to consumers which wish
> to parse the result as binary data, and also friendly to consumers
> which wish to pass it to strcpy or strlen.  Yes, I realize my analogy
> is a bit flawed in that fread doesn't do this.  

I think this is quite reasonable analogy. remote packet is just like a fread. 
packet. target_read_alloc is like some higher-level code, say to read a value 
from config file, or a read entire file into memory. In both cases, the disk 
file don't have terminating nulls and you get zero-terminated char*.

If target_read_alloc does not zero-terminate data, it requires either manually 
zero-terminating result, or drag length everywhere. And while it's possible 
for a remote side to include extra zero byte and increase the size of data by 
one, that's a fairly uncommon interface, and is likely to result in buggy 
stubs. 

- Volodya