From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1444 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: ldso : dladdr support Date: Tue, 7 Aug 2012 16:53:23 +0200 Message-ID: <20120807145322.GH30810@port70.net> References: <5020DA13.6080803@gmail.com> <20120807114627.GG30810@port70.net> <50212306.6070402@gmail.com> 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: dough.gmane.org 1344351218 30306 80.91.229.3 (7 Aug 2012 14:53:38 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 7 Aug 2012 14:53:38 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1445-gllmg-musl=m.gmane.org@lists.openwall.com Tue Aug 07 16:53:38 2012 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 1SylA7-0004zO-Kd for gllmg-musl@plane.gmane.org; Tue, 07 Aug 2012 16:53:35 +0200 Original-Received: (qmail 18087 invoked by uid 550); 7 Aug 2012 14:53:34 -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 18079 invoked from network); 7 Aug 2012 14:53:34 -0000 Content-Disposition: inline In-Reply-To: <50212306.6070402@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:1444 Archived-At: * musl [2012-08-07 16:15:34 +0200]: > On 07/08/2012 13:46, Szabolcs Nagy wrote: > > * musl [2012-08-07 11:04:19 +0200]: > >> This patch adds support for dladdr function. > >> It is based on my previous patch (gnu hash support). > >> > > i havent checked the content of your patch yet > > just had a quick glance > > > > i think before you make substantial changes > > it's better to have some discussion about > > the design > Could you tell me more about the design issues > (I guess this has something to do with function pointers and multi hash algorithms design) ? i didn't have anything specific in mind about the design it was a general remark in case you plan to submit larger contributions about the function pointers: using plain if/else might work, but if you use func pointers then i'd make those part of the dso struct so you dont need an additional lookup step, so dso->hash(s) instead of hashalgo[dso->hashalg].hash(s) in general keep the number of indirections and layers small if possible > >> + uint32_t shift2 = hashtab[3]; > >> + uint32_t h2 = h1 >> shift2; > > i'm not sure if input validation makes sense in ldso > > but shifts can be tricky (hashtab[3] must be in 0..31 here) > By validation do you mean mask the shift value with 0x1F ? i meant that if hashtab[3] comes from outside source and ldso requires strict validation (i don't know if it does) then you need to check the range of it somewhere and return error for bad values