From owner-freebsd-current Fri Dec 20 19:37:38 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id TAA23490 for current-outgoing; Fri, 20 Dec 1996 19:37:38 -0800 (PST) Received: from sdev.usn.blaze.net.au (sdev.usn.blaze.net.au [203.17.53.19]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id TAA23484 for ; Fri, 20 Dec 1996 19:37:29 -0800 (PST) Received: (from davidn@localhost) by sdev.usn.blaze.net.au (8.8.4/8.6.9) id OAA11485; Sat, 21 Dec 1996 14:36:51 +1100 (EST) Message-ID: Date: Sat, 21 Dec 1996 14:36:50 +1100 From: davidn@sdev.usn.blaze.net.au (David Nugent) To: wosch@cs.tu-berlin.de (Wolfram Schneider) Cc: current@freebsd.org, wpaul@frebsd.org.cs.tu-berlin.de Subject: Re: group(5) limits References: <199612170124.CAA02231@campa.panke.de> X-Mailer: Mutt 0.54 Mime-Version: 1.0 In-Reply-To: <199612170124.CAA02231@campa.panke.de>; from Wolfram Schneider on Dec 17, 1996 02:24:34 +0100 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Wolfram Schneider writes: > The current limit is 200 members per group or maximum 1024 character per > line. I changed getgrent(3) to use dynamic allocated buffers > instead static buffers. No member or line length limit anymore - > now 500 members or 5000 members are possible. Good (although it causes me some work too :-)). This was on my todo list. It would be nice if this supported line continuation as well, which I believe is already supported by NIS (at least in the netgroups file). Keeping lines below 1024 characters is kinder on manual management too. > @@ -207,6 +230,9 @@ > if (_gr_fp) { > (void)fclose(_gr_fp); > _gr_fp = NULL; > + free(line); > + free(members); > + maxlinelength = maxgrp = 0; > } > } After a brief glance (ie. nothing in depth and no testing), this however is broken. You can't deallocate that memory - it has to hang around because getgrnam() and getgruid() return group record with pointers to it AFTER calling endgrent(). Try running your code with /etc/malloc.conf -> AJ and using getgrent(). I fixed a similar bug in getttyent() a week ago. With these malloc options, getttynam() always returned junk, and without the usual side-effects when someone allocated/reused the freed block would appear. I'd suggest just leaving these three lines out. Subsequent calls to gr_start() will reuse the memory anyway and add a little to efficiency. Having the static array in spite of its limitations avoided this. BTW, is this a 2.2 candidate? Regards, David Nugent - Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@freefall.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/