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

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

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,
>> [] 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().


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.