Re: [PATCH] zero-terminate result of target_read_alloc

Vladimir Prus
2006-07-18T13:51:17Z

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