qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v6 08/29] libqtest: Let socket_send() compute le


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH v6 08/29] libqtest: Let socket_send() compute length
Date: Tue, 5 Sep 2017 17:20:05 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0

On 09/05/2017 04:54 AM, Markus Armbruster wrote:
> Thomas Huth <address@hidden> writes:
> 
>> On 01.09.2017 20:03, Eric Blake wrote:
>>> Rather than make multiple callers call strlen(), it's easier if
>>> socket_send() itself can compute a length via strlen() if none
>>> was provided (caller passes -1).  Callers that can get at the
>>> length more efficiently are left that way.
>>>
>>> Signed-off-by: Eric Blake <address@hidden>
>>> ---
>>>  tests/libqtest.c | 10 ++++++----
>>>  1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> I have to say that I don't like this idea very much. socket_send()
>> should IMHO not know about the type of the data that should be sent,
>> i.e. it should not assume that the content is a zero-terminated string.
> 
> I agree.

It doesn't assume that the content is zero-terminated unless you pass a
negative length.

> 
>> This also could lead to some hard to detect bugs later in case somebody
>> is calling the function like this:
>>
>>   size = someotherfunction();
>>   socket_send(fd, buf, size);
>>
>> ... and the someotherfunction() returned a negative error code instead
>> of a correct size.
>>
>> So I'd like to suggest to simply drop this patch.
> 
> A separate wrapper function for sending zero-terminated strings would be
> fine with me.

I'm fine dropping the patch; computing the length in the callers is not
that much more onerous (there aren't that many), so I don't think
another wrapper is needed.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]