From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 21523 invoked from network); 7 Jul 2023 14:19:29 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 7 Jul 2023 14:19:29 -0000 Received: (qmail 15922 invoked by uid 550); 7 Jul 2023 14:19:27 -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 15890 invoked from network); 7 Jul 2023 14:19:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=s31663417; t=1688739554; x=1689344354; i=nullplan@gmx.net; bh=pjYleP/ypR66dEwhJuL4h+dNVbkuchIw1ZGl2OST50c=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=dLGT/eRJ9fSYmlTclSUg/5AS8If4l1/aA90QYD+C2Bs+X5a1N0LfAUqX5WvuEWC15d6LW/Q r7txHsMRgJmo08KswtH+/xb0nIpfeDsNYzadMrviUl78yoxKpKQyQnb3CwEefwPZxYTJ/YsgX USoQj++LhhRO51LP+iYGsLAXo35uTzCq2/pvP2Bh9N4ZvErB9OFAaYiviBXINSCTy63/Munyk JNLQYdu+UD0VUg5foY+y5pR1NnUx1qcINq8r9qRoMM4qY9OpAs1hXgWCUvwIAIpx5gzXn5Dii d5C8Gl2MsSRy3X92uguHFsenJF7PPrz6AYxU0sZ0BQutH4sW50fQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Date: Fri, 7 Jul 2023 16:19:14 +0200 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: References: <309EDCC9-2402-46B5-BDBD-B96677E470DD@apple.com> <20230707124722.GE4163@brightrain.aerifal.cx> <054B1907-817E-496D-9F83-7FBE7AB0111A@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <054B1907-817E-496D-9F83-7FBE7AB0111A@apple.com> X-Provags-ID: V03:K1:tSvW8E9HXJh/FdPDPKgDCW/TstIBu64+38Aj/SwoHTD/QHo/WR8 NRTVUx3BjxVcmI6Fc1ihSAhKlwh/UB38BZf7ubqzZc+m6LxhJl01/edyRcd7dGF5uQsE9w1 k57MotPidnvAg3KC7xIUB8RVMVMI5SsmLzGTdRC/W2wrUds1d1qsGakYrMKEUHuAT2zWT9T LwDLTM2SSnrvxFC2mpJkw== UI-OutboundReport: notjunk:1;M01:P0:E6lbsObHEnY=;/pE/kq/iPdbMh5vV0DnNJJUk0qd V/FnvY/WuCHaNIqXRpxKbCkHdRAqxupX0dxEsSAZuBcOBA8V0Immyr7GEjf/Jl/V+cVMSUCwT Q0G6H9sKaT3b74iPjuI7f7gP+BU0k6TYu9vEyd4kjX5hBsSE4agQ79JcU5veuEvIAE1iAAira xd6fCh0GVkgTiFk5j1FuO/zZP5tHybVfHCb3Kc8W58/AuQnWb3yx2Wj2UF1kfrk3awo8gMn3g JvKJ89kkloaixaMhsmHR2ut2ijXfJtu4MIOs6cy5HbV+A3qmXRNVvApoxICH5aRgff1OCUGx6 WPk9oap2wTDIQmNFq813i/BAsiX6XFPTlX9y0X+OwJ0acQn7vWe5ReW/BrDbi8ZdRWxs+yiTW 7tNd/yv64MHeuasFiukJg4/JwQbL6LZ50Zniwz3XSjNjA4cONEZhqhudWxOTx/9D6a/oT14At KDZOXms9nECb8Ahau+/qCRgI2alCdomslabJDa0UHzKmlPW1Ma/SBO9OTU8Ub7sKIqegMcYSg It387ZDfUrfd0BcOt9d/GASqmKl7SjILIJkjgD+J5lh/i6a0UTAmvX0y05D4vipZoNa8q8QpC /Uy5HW6zSAZ/J56/jFjDYWnf0j0PuuxevHnUhrdbUl5IMnJYDm9WUm38vz72c5fM6Ls+FgFZq D/8byelKXfnBxRrbFXSOo0+vovKlVDtzEZKkZ0mzEzbfCfgXVxtEog/za0e2isiY7i91l1ibJ e0A2xTTkJVKLuVWF0S0c8awxiE6xKuzmvn2+XqP6hfJuiQ7raHib/RuAmhoDDB+O1RQRIuWw0 UKYd4BN6cQ7Hx4YM/TlkF7bX6/13Hh2yPkqVbVjMf7Ci4owBaQ5s/AT8Cy2eUrYzJ3T60ie/p yyx0DcMAsnlCdYSlVjt5syX1SQUB0gmjtG2szdY5Wn9QPmy9ywFer1XKEnTOqRO8Qa0+/pGIQ ysTvQLyKs8cqMaMhHhHRWkj19Q4= Subject: Re: [musl] __MUSL__ macro Am Fri, Jul 07, 2023 at 02:14:30PM +0100 schrieb Alastair Houghton: > This is a somewhat irrelevant distraction and I rather wish I hadn=E2=80= =99t > mentioned that as an example of odd behaviour. I=E2=80=99m well aware t= hat > you cannot copy or assign `pthread_mutex_t` values in general (and I > understand the reasons why). > > Please can we instead focus on the issue of whether or not musl should > have `__MUSL__` and `__MUSL_MINOR__`. > The counter-examples are not irrelevant. That is precisely the point. Nobody advocating for implementation identification macros has so far given a valid reason to do so. Every single one so far has turned out to be spurious. Well, I tell a lie, there is one case with a shadow of reason behind it: Header-only libraries. But maybe the problem with those is trying to be a header-only library. If you have different implementations with different runtime behavior, check whether the behavior is acceptable from the specification. If it is, write code that can accept the behavior. If it is not, write a bug report. Very often I am astonished that the problem presented is claimed to have the __MUSL__ macro as a solution. I am reminded of a Stack Overflow question where someone wanted to identify musl, because musl doesn't have a trustworthy vfork(). Pressed on what exactly he meant, the poster said that depending on version and architecture, calling vfork() with musl actually results in it calling fork(). OK, that was his concern. His solution? If he found he was running on Apple or musl, he wanted to call fork() instead of vfork(). Why he would not just always call vfork() if the claimed untrustworthy behavior was also his remedy is a question the guy skillfully avoided an answer to. In your case, apparently there is a way to deal with failing dladdr(). So why don't you put the code for that in the failure path for the call, instead of into "#ifdef __MUSL__"? That way, even unknown implementations would be supported. For header-only libraries, the customer could configure them at build time. I have so far not figured out why people that write programs for a living cannot be expected to fill out a config.h template. There was a person here before who wanted a macro to identify that qsort_r() is available, and I told him much the same thing, and never got a satisfactory answer to the above query. Also, he already had his own fallback sorting algorithm, so the portable solution was just to call that, and then the whole need evaporated. I remain in staunch opposition to identification macros, because those have so far always - no matter how benevolent they might have seemed at the beginning - lead to #ifdef hell of levels Dante couldn't dream of. They lead to people writing bad code and making bad assumptions. None of this matters one bit, because Rich is God as far as musl is concerned, and he has not weighed in yet. However, in the past he has spoken out against these macros, and I doubt your arguments have convinced him. They haven't convinced me, at any rate. Ciao, Markus