[libvirt] [PATCH]: don't harcode buffer for getgrnam_r

Ryota Ozaki ozaki.ryota at gmail.com
Thu Apr 16 14:37:24 UTC 2009


Hi,

On Thu, Apr 16, 2009 at 10:40 PM, Daniel P. Berrange
<berrange at 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 ;-)

Thanks,
  ozaki-r

>
> Daniel
> --
> |: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
> |: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
> |: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
>
> --
> Libvir-list mailing list
> Libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
>




More information about the libvir-list mailing list