On Mon, Nov 18, 2019 at 03:20:00PM +0100, Erik Skultety wrote:
> On Mon, Nov 18, 2019 at 01:50:03PM +, Daniel P. Berrangé wrote:
> > On Mon, Nov 18, 2019 at 02:26:31PM +0100, Erik Skultety wrote:
> > > On Mon, Nov 18, 2019 at 01:04:01PM +, Daniel P. Berrangé wrote:
> > > > On Mon, Nov 18,
On Mon, Nov 18, 2019 at 01:50:03PM +, Daniel P. Berrangé wrote:
> On Mon, Nov 18, 2019 at 02:26:31PM +0100, Erik Skultety wrote:
> > On Mon, Nov 18, 2019 at 01:04:01PM +, Daniel P. Berrangé wrote:
> > > On Mon, Nov 18, 2019 at 01:18:19PM +0100, Erik Skultety wrote:
> > > > It doesn't make
On Mon, Nov 18, 2019 at 02:26:31PM +0100, Erik Skultety wrote:
> On Mon, Nov 18, 2019 at 01:04:01PM +, Daniel P. Berrangé wrote:
> > On Mon, Nov 18, 2019 at 01:18:19PM +0100, Erik Skultety wrote:
> > > It doesn't make sense to pass a target buffer into an API, declaring its
> > > size as 0 and
On Mon, Nov 18, 2019 at 01:04:01PM +, Daniel P. Berrangé wrote:
> On Mon, Nov 18, 2019 at 01:18:19PM +0100, Erik Skultety wrote:
> > It doesn't make sense to pass a target buffer into an API, declaring its
> > size as 0 and expect some meaningful result. Since this used to work
> > pre-Glib
On Mon, Nov 18, 2019 at 01:18:19PM +0100, Erik Skultety wrote:
> It doesn't make sense to pass a target buffer into an API, declaring its
> size as 0 and expect some meaningful result. Since this used to work
> pre-Glib era, we shouldn't end with an error, but we can return 0
> for the number of
It doesn't make sense to pass a target buffer into an API, declaring its
size as 0 and expect some meaningful result. Since this used to work
pre-Glib era, we shouldn't end with an error, but we can return 0
for the number of domains immediately, instead of calling into the
daemon, which is
