Re: [Qemu-devel] [PATCH 04/18] nbd/client: refactor nbd_receive_starttls - Vladimir Sementsov-Ogievskiy

From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
To: Eric Blake <eblake@redhat.com>,
	qemu-block@nongnu.org, qemu-devel@nongnu.org
Cc: famz@redhat.com, jsnow@redhat.com, kwolf@redhat.com,
	mreitz@redhat.com, pbonzini@redhat.com, armbru@redhat.com,
	den@virtuozzo.com, stefanha@redhat.com
Subject: Re: [Qemu-devel] [PATCH 04/18] nbd/client: refactor nbd_receive_starttls
Date: Fri, 10 Feb 2017 14:23:36 +0300	[thread overview]
Message-ID: <e0ec9530-a87d-0f10-262d-4b2af4516eed@virtuozzo.com> (raw)
In-Reply-To: <de548107-dbff-36ca-96ba-fead03589fde@redhat.com>

09.02.2017 17:41, Eric Blake wrote:
> On 02/09/2017 12:20 AM, Vladimir Sementsov-Ogievskiy wrote:
>> 07.02.2017 19:32, Eric Blake wrote:
>>> On 02/03/2017 09:47 AM, Vladimir Sementsov-Ogievskiy wrote:
>>>> Split out nbd_receive_simple_option to be reused for structured reply
>>>> option.
>>>> +    return "<unknown option>";
>>> Can you please consider making this include the %d representation of the
>>> unknown option; perhaps by snprintf'ing into static storage?  While it
>> Hmm.. The caller should free it in this case.
> Only if you print it into malloc'd space. I think that printing it into
> static storage may be sufficient (although then we have a race if more
> than one thread is trying to use that static storage at the same time -
> but do we ever have more than one thread trying to handle an error at
> the same time?).
>

This race would be if one thread decides to print two option names in 
one message. Or save one option in a var, then print other, then print var.

-- 
Best regards,
Vladimir