From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3348 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 18:26:04 -0400 Message-ID: <5199517C.8040403@eservices.virginia.edu> References: <5199324A.7020805@eservices.virginia.edu> <20130519210341.GG20323@brightrain.aerifal.cx> <51994949.1060305@eservices.virginia.edu> <20130519220941.GJ20323@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 1369002379 25578 80.91.229.3 (19 May 2013 22:26:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 May 2013 22:26:19 +0000 (UTC) To: Original-X-From: musl-return-3352-gllmg-musl=m.gmane.org@lists.openwall.com Mon May 20 00:26:19 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 1UeC3X-00087I-7G for gllmg-musl@plane.gmane.org; Mon, 20 May 2013 00:26:19 +0200 Original-Received: (qmail 18103 invoked by uid 550); 19 May 2013 22:26:18 -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 18092 invoked from network); 19 May 2013 22:26:18 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 In-Reply-To: <20130519220941.GJ20323@brightrain.aerifal.cx> X-Originating-IP: [128.143.141.130] Xref: news.gmane.org gmane.linux.lib.musl.general:3348 Archived-At: On 05/19/2013 06:09 PM, Rich Felker wrote: > On Sun, May 19, 2013 at 05:51:05PM -0400, Z. Gilboa wrote: >>> My preference is that either long pathnames should be truncated in a >>> reasonable way (keep in mind that the message is *not* parsable by the >>> caller; the only way it can be used is presenting it to the user) >> certainly; the initial motivation was log-file processing. >> >>> or >>> larger buffers should be dynamically allocated. The only reason I did >>> not go the dynamic-allocation path to begin with was to make it so >>> non-thread-safe usage of dlerror yields (at worst) corrupted messages >>> rather than crashes. This can also be achieved with dynamic allocation >>> (as long as the old too-short buffer is never freed), but it's more >>> complex. >> In my understanding, the current approach of having a fixed buffer >> size is by far the superior one. > Could you elaborate as to why? Are you concerned about memory usage? > Code complexity? Or some other reason? A little bit of both, with complexity being the main factor. As far as I can tell (from looking at dynlink.c and otherwise), there is only one case (do_relocs) where both the library name and symbol name are sent to the buffer. So given the case's rarity and singularity, I would not introduce "complex" code or memory allocation into the function. We should also remember that this is not about how the error is being handled, only about how it is being presented, meaning that less code is probably better... > > Rich