On Thu, Apr 16, 2009 at 11:37:24PM +0900, Ryota Ozaki wrote: > Hi, > > On Thu, Apr 16, 2009 at 10:40 PM, Daniel P. Berrange > <berrange@xxxxxxxxxx> wrote: > > On Thu, Apr 16, 2009 at 02:14:13PM +0200, Guido G?nther wrote: > >> On Thu, Apr 16, 2009 at 09:56:27AM +0200, Daniel Veillard wrote: > >> > On Thu, Apr 16, 2009 at 09:19:38AM +0200, Guido Günther wrote: > >> > > Hi, > >> > > determines the maximum needed buffersize for getgrnam_r using sysconf > >> > > instead of hardcoding it to 1024 and increases the buffer on ERANGE. > >> > > The latter is needed since sysconf is allowed to return -1. Furthermore > >> > > some glibc versions seem to return a too small buffer on amd64 > >> > > (http://bugs.debian.org/520744). O.k. to apply? > >> > > >> > It looks a bit weird, using sysconf but 1/ allowing it to fail so > >> > doing the 2/ 1024 value and loop on ERANGE , but well if I understand > >> > correctly taht's forced by some glibc broken behaviour. > >> Yes, sysconf is allowed to return -1 here. > >> > >> > My take is that the *= 2 size loop should be bounded to avoid eating > >> > all memory on some intermediate not size related error. Can we really > >> glibc shouldn't return ERANGE then, but better safe than sorry. I've > >> added that check in the attched patch. > > > > ACK. > > I think it's more useful that such a function is implemented as a wrapper > function like virGetUserDirectory() in util.c, because other drivers might > use the function. Actually my patch sent just now implements > virGetGIDByGroupname() > in util.c ;-) Yes, it's more useful to have this in util.c when we have more than once caller (which we hadn't so far). I'll move remoteReadConfigFile over to virGetGIDByGroupname once it's in. -- Guido -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list