From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3352 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: patch: make the size of errbuf configurable Date: Sun, 19 May 2013 20:21:19 -0400 Message-ID: <20130520002119.GL20323@brightrain.aerifal.cx> References: <5199324A.7020805@eservices.virginia.edu> <20130519210341.GG20323@brightrain.aerifal.cx> <51994949.1060305@eservices.virginia.edu> <20130519220941.GJ20323@brightrain.aerifal.cx> <5199517C.8040403@eservices.virginia.edu> <20130519232209.GK20323@brightrain.aerifal.cx> <5199699F.4050009@eservices.virginia.edu> 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 1369009292 16930 80.91.229.3 (20 May 2013 00:21:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 May 2013 00:21:32 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3356-gllmg-musl=m.gmane.org@lists.openwall.com Mon May 20 02:21:33 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UeDr2-0005QJ-Jy for gllmg-musl@plane.gmane.org; Mon, 20 May 2013 02:21:32 +0200 Original-Received: (qmail 20271 invoked by uid 550); 20 May 2013 00:21:31 -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 20263 invoked from network); 20 May 2013 00:21:31 -0000 Content-Disposition: inline In-Reply-To: <5199699F.4050009@eservices.virginia.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3352 Archived-At: On Sun, May 19, 2013 at 08:09:03PM -0400, Z. Gilboa wrote: > > From what I can see, complexity can be avoided and maybe even reduced > >by refactoring the code so that all the places that set an error > >message call a short simple function that wraps snprintf and allocates > >a new buffer if needed. The complexity reduction would be if we can > >eliminate duplicate logic at each call point, which I haven't checked > >yet. > > > >Rich > > When moving beyond dynlink.c then yes, I believe, that should be > beneficial. I just had a quick look at the places where snprintf is > used, and found that the following functions might benefit from the > above wrapper: I was just looking at dynlink.c, but we could consider whether the same issue applies in other places. I doubt the same function would be useful in other places though since some of the logic I'd want to factor would be dynlink-specific. Basically, I would want the function to also encapsulate the dynlink error handling code (usually longjmp or printing an error message). > dynlink.c: all functions that call snprintf > syslog.c: _vsyslog Indeed there's a question of what syslog should do when the message is too long. But unboundedly-long messages can't really be supported anyway; the ultimate upper limit is the max unix socket datagram size. > getnameinfo > inet_ntop (unsure) Not necessary. All strings here are highly bounded in size, and in most (all?) places they're using caller-provided buffers anyway. > sem_open (unsure: _name_ can be up to 251 characters long > (http://man7.org/linux/man-pages/man7/sem_overview.7.html), but is > link to _tmp_ which is only up to 64 characters long) I'm not sure what you're saying here. All of the strings here are highly bounded in size, as you noted. There's certainly no need for dynamic allocation of the name buffer, which would introduce an additional failure case. Rich