From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3354 Path: news.gmane.org!not-for-mail From: "Z. Gilboa" Newsgroups: gmane.linux.lib.musl.general Subject: Re: patch: make the size of errbuf configurable Date: Sun, 19 May 2013 20:37:30 -0400 Message-ID: <5199704A.5040704@eservices.virginia.edu> 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> <20130520002119.GL20323@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1369010265 24397 80.91.229.3 (20 May 2013 00:37:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 May 2013 00:37:45 +0000 (UTC) To: Original-X-From: musl-return-3358-gllmg-musl=m.gmane.org@lists.openwall.com Mon May 20 02:37:45 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 1UeE6j-0007KY-B9 for gllmg-musl@plane.gmane.org; Mon, 20 May 2013 02:37:45 +0200 Original-Received: (qmail 30018 invoked by uid 550); 20 May 2013 00:37:44 -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 30010 invoked from network); 20 May 2013 00:37:44 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 In-Reply-To: <20130520002119.GL20323@brightrain.aerifal.cx> X-Originating-IP: [71.206.170.124] Xref: news.gmane.org gmane.linux.lib.musl.general:3354 Archived-At: On 05/19/2013 08:21 PM, Rich Felker wrote: > 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). alles klar... > >> 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. My mistake. I wasn't sure why the size of _tmp_ was different, however I now see that the two sizes are independent of one another. > > Rich