On 04/06/2016 02:27 PM, Wouter Verhelst wrote:
>
> Also, most of those strings exist solely to make user interaction
> easier. In that context, a 4K string is *way* too long; I'm thinking
> something like 256 seems saner (80 characters, times three because
> UTF-8, round up to the next power of two).
For that matter, the existing qemu-nbd server has:
static int nbd_negotiate_handle_export_name(NBDClient *client, uint32_t
length)
{
int rc = -EINVAL;
char name[256];
/* Client sends:
[20 .. xx] export name (length bytes)
*/
TRACE("Checking length");
if (length > 255) {
LOG("Bad length received");
goto fail;
so we have existing practice of names larger than 256 causing connection
issues. SHOULD rather than MUST is appropriate here (for
interoperability, limit yourself to the common denominator, but where
you control both client and server, knock yourself out with something
larger).
>> There are a number of error reply types, all of which are denoted by
>> having bit 31 set. All error replies **MAY** have some data set, in which
>> -case that data is an error message in UTF-8 encoding suitable for
>> -display to the user, with no embedded or terminating `NUL` characters.
>> +case that data is an error message string in UTF-8 encoding suitable for
>> +display to the user.
>
> Can drop UTF-8 reference (since you say string)
Should we capitalize the term String (or use any other typographical
convention) to call out when we mean the UTF-8 string as defined above?
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature