Re: [Xen-devel] [PATCH v3 21/28] tools/libxl: Infrastructure for writing a v2 stream

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 13/07/15 16:47, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [PATCH v3 21/28] tools/libxl: Infrastructure for 
> writing a v2 stream"):
>> On 13/07/15 16:21, Ian Jackson wrote:
>>> Sadly this pattern is not correct.  I don't think this initialisation
>>> ensures that the memory in hdr is all-bits-0.
>> It guarantees that all object have their default values, which is 0 for
>> PoD integers.  (On a POSIX system, it is only floats/doubles/_Complex
>> which have default representations with not all bits 0)
> Yes.
>
>> From the standard,
>>
>> [6.7.8.21] If there are fewer initializers in a brace-enclosed list than
>> there are elements or members of an aggregate, or fewer characters in a
>> string literal used to initialize an array of known size than there are
>> elements in the array, the remainder of the aggregate shall be
>> initialized implicitly the same as objects that have static storage
>> duration.
>>
>> i.e. everything will get the same value it would have done had it been
>> declared static.
> But it does not guarantee that the padding is initialised to
> all-bits-0.
>
>
>>>> +/*----- Success/error/cleanup handling. -----*/
>>> As with read, I would prefer these to be unified into one
>>> stream_complete function.
>> They can't, because of differing function signatures from callbacks.
> You are right about stream_success but not AFAICT about
> stream_complete.
>
> Ie, stream_success could be simply
>
>   stream_complete(egc, stream, 0)
>
> But maybe you prefer not to, so I won't insist.

stream_success is used as a callback, but I see your point.  I had
intended to refactor stream_success() in terms of stream_complete().

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel