From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7577 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: fgetgrent_a questions/review Date: Thu, 7 May 2015 12:49:38 -0400 Message-ID: <20150507164938.GT17573@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1431017399 1156 80.91.229.3 (7 May 2015 16:49:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 7 May 2015 16:49:59 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7590-gllmg-musl=m.gmane.org@lists.openwall.com Thu May 07 18:49:55 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YqOzi-0003eb-Bi for gllmg-musl@m.gmane.org; Thu, 07 May 2015 18:49:54 +0200 Original-Received: (qmail 6118 invoked by uid 550); 7 May 2015 16:49:52 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 6097 invoked from network); 7 May 2015 16:49:51 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:7577 Archived-At: On Thu, May 07, 2015 at 05:53:43AM -0700, Kevin Bowling wrote: > Hi, > > I borrowed the fget*ent_a functions to port libnss-cache to FreeBSD because > the fgetent family of functions are not standard and the musl > implementations looked clean and compact with a good license. > > https://github.com/google/libnss-cache/pull/1/files#diff-800bf143f84497855c6338a07c19b4af > > I had to make a few changes which may be suitable for musl. First, getline > seems to resize the buffer as it pleases but this causes problems since the > glibc implementation uses fgets and generally something higher up the call > stack handles the resizing. Second, the current musl implementation > doesn't return ERANGE which was necessary to get the caller's (nsswitch) > code to do the right thing to the buffer. The way the code is factored in musl, with the internal function (getgrent_a) being allocating/using getline, is very intentional. Implementing getgrnam/getgrgid in terms of their *_r versions and retrying on ERANGE would be possible (albeit inefficient), but getgrent cannot be implemented that way because it will have messed up the iterator state already. Minimal code duplication and runtime efficiency is achieved by having the internal function always succeed (except on resource errors like ENOMEM or EMFILE/ENFILE) and the wrapper functions for the *_r interfaces attempt to copy the data into the caller-provided buffer and report ERANGE if the data doesn't fit. If a different factoring works better for your project, by all means use it, but I don't think it would work for what musl needs. > Finally, I wasn't quite sure what to do with mem and nmem in this case. I > made mem static, and pass nmem in in a wrapper function.. but I do not know > if these are allocated and freed correctly used standalone like this? I don't know what libnss-cache's API is like, but this sounds unsuitable. It's definitely not thread-safe or library-safe (multiple-caller-safe). Rich