Re: [PATCH] zero-terminate result of target_read_alloc

[Jim Blandy <jimb at codesourcery dot com>]

Vladimir Prus <vladimir@codesourcery.com> writes:
> 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.

Another way to look at it is to say that target_read_alloc clearly
operates on blocks of uninterpreted bytes --- it returns address and
length, after all --- but the interface as given requires users
retrieving text that they'd like to process as null-terminated strings
to make an extra copy.  The change to the interface Vlad's proposed
would make the copy unnecessary.

Of course we can't accomodate every random string representation
anyone could come up with; we can't avoid copies in every case.  And
it's not our job to do so.  But null-termination is a common need, and
one actually at hand.

Examples from elsewhere: in Guile, even though our strings could
contain arbitrary binary data, we also included an extra null byte at
the end, beyond the official length of the string, so that C code that
knew it was working with text (filenames, for example) could simply
use the string contents in place, without needing to make a
null-terminated copy.