[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



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.

Ian.

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


 


Rackspace

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