Daniel Veillard wrote: > Hum, looking at the bugzilla it's for storage that the problem was raised. > It's a bit annoying, the main domain and network functions accept a max = 0 > The documentation of virConnectListDefinedStoragePools doesn't prevent > maxnames = 0 > > Actually the check done in the function is > if ((names == NULL) || (maxnames < 0)) > > i.e. it allows 0, and pass it to the underlying driver. One solution > would be to just return 0 there, as attached in this patch, the other > solution would be to check which underlying storage driver failed and > fix it, Right. After going through this, I found out that it is actually a NULL check firing, not a 0 check (see my posted patch for details). That being said, a patch of the type posted here might be worthwhile; it would short-circuit the rest of the calls through the stack, and in particular would avoid on-the-wire calls in the remote case, to do essentially no work. I think it would be a nice optimization for all of the List type operations, but not necessarily required. Chris Lalancette -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list