From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by inbox.vuxu.org (OpenSMTPD) with SMTP id e844e445 for ; Sun, 19 Jan 2020 11:07:59 +0000 (UTC) Received: (qmail 24077 invoked by uid 550); 19 Jan 2020 11:07:56 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 24043 invoked from network); 19 Jan 2020 11:07:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1579432064; bh=OqwNvz270mKWykzVGY624weZLZGA7e6EyBkDM1GMg/g=; h=X-UI-Sender-Class:Date:From:To:Subject; b=DAG470+UmFGj14EdjrMBaxIDB/aFpuOtrsFB800qbsDBPArjTgHCUcxnSGFtFvgaw lLD988MwxgC1EBRETQQNuxdxTBwlmSShy8G17J3vO7XSwLFIHTuHdj3yDewH7LbaO9 oAfry1hqA+FEdsNFiMZetlrAiqlb2A2JtanNllF0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Date: Sun, 19 Jan 2020 12:07:43 +0100 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: <20200119110743.GD2020@voyager> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="ZGiS0Q5IWpPtfppv" Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) X-Provags-ID: V03:K1:BMk2tOb03IrJp1o4gyNNn5MSBHnfW1wGUSALGLPyqZNlIKv9oKn UA34Y7ounJdpmHz1Q3Sf/EW2RA/yPl2hQAzxjlZlxF5T/u8tLOehEAAVfM5TOvdwWBlMwA+ XpJ1m7E7zNKSLEjU3xe29JoN/k/YmZYCzfJ78c6M1s2RPxvA9avDRX+u8oLBEj4k3q5OON4 itKwwMO7Q3+l+Apoz/7xg== X-UI-Out-Filterresults: notjunk:1;V03:K0:tpNmwiXhRR8=:ujXJiopVYD+SfJJzzoWLHe 1MVWtUJf17qJvNe38nTN/X73XnnzAZZ3Pjpm/dHzO/pwsWuNsgPoeZo5ubftPgxW6PtIFGPLq B1lIQEGyHnOjUgBSA5tU0Qscva2hkg1CZnZ2hXciknWhfkw0iei7zucYGfWyf75XZIz455Gxn 16+VuLNPs0Aj6BfJwl/Ne8GOmUrkh2jSAZaiOs7ySA1fpgq5ME/0dJ56kETcVtJDIZe9Yg1N2 rfq21oUhPDLAGYzSecNpSz8d6GHNVMRC71Xgdqxdw+N2YJUEqDzbQvXY0BWYmFwHauTYu/UZz BtK98z9jBvMRcW5noqiJUEDsuyDuCmd8dF8O4AQy4zl++Gf8haLKN8KqxgffNdzrQr/2hE7Q5 kNnlsOPQHY9/ztGkNwDHrs43QW+sHo9zVcL+pMJAupk6Z2+4vQ3wj7F973+aMqUZsRGZa1k5D BpdTtrKJAuGZd1JBQ8Mrz1gRoQU8SU/OdiTPRZ6trVYiCNOUs5Ge1v27yjdRRck885jeOxv9k 7DxT5dyKEnfGdlB2Pjk0nP039EkPcVvD8qdNyzY9zZ4QQYLXHunVCXH/2PPKblCVfvPu5k5j5 Lk509lQEg7O62yuI4kIecIpO3bePqvMIrU9zCqDqYvZGlAGk0G1z/23UHj6FX73PoVV0lbujq I/kM3sUM3NBeXUPRyfJrYW3vjrVhMSzlFVp2xtnkcUBeUi7QbTdr4tDh6dlB7CadI8i6FI5rs pVgIVgF/ZeuCornX6aNLOlzK4uzAufYN48m5u1FMAVb4YsRnPLIxA/gPWyz03kkyC7o1TJww1 G+Jpkm+aCO/fTK9LPIK1UJme/w5yJ7XkzyJAhIG+cK7oVfc9ll8F9g4Gczi44cLBRhBIR9IBB ixteidZqhv3+wcthyBwTMl1FxRi5ngTGsUcjyxpY6nOrrifHM67qM/8tYVRSUZ3FUGzWSiYtv b35rUlRsXUfu2lCsrEAyNLuSgs3pIH8H9uiOEiF+x77ph3Dtx1cQyFqYotAkQMxBJLyN2pvU5 qSF/bKoNUOMZLtAi6Br+SjZn4zrLhMDHBvFbP1MWccFmeUzuLcSU0wCgc4W8Aawz/OeIrvKQA ZOR5dobzXZPR/51NkJxqwfO8u5rbkP7IvDRrWZ8LtmmpDdC7yCaK7su1f4ugHmdpoB2+h2Hle a6+IlwONNFlulIYAsAJPpQpobhCDQGA11lW1bSy9bn3Sm4u9SP8m6GKEDBY0F8Wb9889SeGk8 mecSwcW6lZlISyMER4Mzou3yg99fAj/wA6U8+nA== Subject: [musl] Minor style patch to exit.c --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi all, it has often been said that if a LISP programmer were tasked with catching an elephant, they would build a maze of parentheses in which the elephant gets lost. If so, then libc_exit_fini() provides a nice starting point for such a maze, even if it was started in C. In all seriousness, the logic of the function is to iterate over an array of function pointers, so why not write down that that's what it does instead of iterating over some numbers that happen to be convertible to such? Or is there something I have missed? Ciao, Markus --ZGiS0Q5IWpPtfppv Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0001-Make-libc_exit_fini-easier-to-read.patch" Content-Transfer-Encoding: quoted-printable =46rom 44e09392c72cbd72c1e5b4ec3dea71f9b38e13c8 Mon Sep 17 00:00:00 2001 From: Markus Wichmann Date: Sun, 19 Jan 2020 11:58:51 +0100 Subject: [PATCH] Make libc_exit_fini() easier to read. The previous version did have a maze of parentheses here. But the actual logic of the function is not to iterate over some numbers that happen to be convertible to pointers, but rather to iterate over an array of function pointers. So let us use pointer arithmetic correctly. =2D-- src/exit/exit.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/exit/exit.c b/src/exit/exit.c index a6869b37..e02ba2be 100644 =2D-- a/src/exit/exit.c +++ b/src/exit/exit.c @@ -16,9 +16,9 @@ extern weak hidden void (*const __fini_array_start)(void= ), (*const __fini_array_ static void libc_exit_fini(void) { - uintptr_t a =3D (uintptr_t)&__fini_array_end; - for (; a>(uintptr_t)&__fini_array_start; a-=3Dsizeof(void(*)())) - (*(void (**)())(a-sizeof(void(*)())))(); + void (*const *a)() =3D &__fini_array_end; + while (a > &__fini_array_start) + (*--a)(); _fini(); } =2D- 2.17.1 --ZGiS0Q5IWpPtfppv--