From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (wildebeest.demon.nl [212.238.236.112]) by sourceware.org (Postfix) with ESMTPS id D7EEA385DC1A for ; Sun, 6 Dec 2020 13:41:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D7EEA385DC1A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mark@klomp.org Received: from tarox.wildebeest.org (tarox.wildebeest.org [172.31.17.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id DCE4C37251C6; Sun, 6 Dec 2020 14:41:54 +0100 (CET) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id C4E68413CB2B; Sun, 6 Dec 2020 14:41:54 +0100 (CET) Message-ID: Subject: Re: link_map: Remove nested functions From: Mark Wielaard To: tbaeder@redhat.com, elfutils-devel@sourceware.org Date: Sun, 06 Dec 2020 14:41:54 +0100 In-Reply-To: <20201201083854.1870943-1-tbaeder@redhat.com> References: <20201201083854.1870943-1-tbaeder@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-10.el7) Mime-Version: 1.0 X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2020 13:41:56 -0000 Hi Timm, On Tue, 2020-12-01 at 09:38 +0100, Timm B=C3=A4der via Elfutils-devel wrote= : > the attached patches get rid of nested functions in > libdwfl/link_map.c. >=20 > I wrote these a while back and just looked at them again and we could > use the same read_state struct here as well. I just quickly checked, > but it seems a bit more involved due to the > integrated_memory_callback > handling. I can look into that anyway if required. I had some comments on the first patch, the third patch seems fine and has been committed. If you have adjust for the changes in the first patch it would be nice if you could look at making the second patch read_addrs function take a bit less than 11 arguments, Note that all patches were missing ChangeLog entries and Signed-off-by lines. Cheers, Mark