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@redhat.com> 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