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.1 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,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 29442 invoked from network); 6 Jul 2023 12:18:18 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 6 Jul 2023 12:18:18 -0000 Received: (qmail 28379 invoked by uid 550); 6 Jul 2023 12:18:15 -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 28347 invoked from network); 6 Jul 2023 12:18:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s2048; t=1688645882; bh=/yNnL4pQ5gRweemyBZlbDLzqb1INbc0NfLYcgrkoQ0M=; h=In-Reply-To:References:Subject:From:To:Date:From:Subject:Reply-To; b=K8UKezhgtD5MDpU5zdxcdqvCOFB/bq2NebPHuCKGcKkVwsDr9ME1hki+NGkz6Xb8LCcxHogSfW0Jmkdqp6KYULIA14tx0q/kZvdBsJam9eKLwYhVEMTVIxgHYDBCQ36uaHBE/6BMGkREA1mju5rr8+dy/x5YfA+eXdCUkHLFtS40aYf+WF63sKfikSsMjiTkUieVleAWopUl7eRl6Vbnn1Qhz9MOq/WkixbZr88vuxivnoEIaRHHh5894SxkTf0am8Bu6JevS1CLAKpV8RQnQwBCPQGDWiLwE45ozMn4iFohz4P9mMdh7aBJ4qj5nEtFw4oCYIq9U1nf1evkr3OVEA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688645882; bh=mLgobS+r7cO0rUbheEuym6A392WS6zptzPjjlAW4N9Y=; h=X-Sonic-MF:Subject:From:To:Date:From:Subject; b=aSlLSWS6n9d1AK2Hk49DMobs0W1zl598mHUqygXojQ5a0JpehMo35cdlUDkNbSJDS+8WTycV+jUlpK3/CNOnX/G5bB+sXiH6jKupYIa8LpUSX32PteNWDMXQuwirfvgCAUeDAVlA/tkuoDafhloLVHTM+hQJTahnjoWswXN6a6oc/+sTzTpeWPo3/au20BD1sUQdpN6d6XDJlOdmNxe19Z4mtfW89rB+VLFOS9sr1r6+Bl3eH7DUvOgERca5z2dNsLbnMVv8NxOhRiF7mIoNdFtb/cY6LuXEeNeMUOveTV7pTL7sT2UVCt+EnzUVLeaeLPDKK9h7sBf4rdpl2y/ecA== X-YMail-OSG: CmL7A7kVM1n7virTUIPrGa0IxLGMU1j5fYP0YOPy6LS_bj7ZJHqUaQgG.0SSi4w W9TZbhoTfvFSVInsez.f1l01Di7xmL6r9YqL7Ga.9_vheC8R8pFkBm63v1Jr7GYw_8oDnbOcx_IA aLysAqSuom5iANed2NN0O.UbvzeYDIu2.zkOgdksgYiIvfGndrgBZ1zICN6Xv5HUGHvX8kT.v3tI GPcWr3ZdIuoVFIMUE48MKSDNL0TeY4pOwamyRPHT3K1DT_h1J3W33Eu2ZZHPO3ZcpqvYGsyaomSU G1VqwIqS44q0yTPq9FwTKkbWRJ_yxU6vxzUkDrNP04jj0SqpuZU4NXyyJJVlL3Q0ZLAFaeF0yLIT _p2HaZIi_yOc7J_HKXrW_5lGJuZlJfr09_im2v2j26ymPr3Is.7FP82Fy6aZMklUQ6MI8HHTRidW bUrkjvzCftqPi1dl3qTVztjruSABwbVoh_ddPMTrXqg1g0m.FMQ0eFnufJip74GKOUxhwCfbCx0Y kxHh75la2szm5aSJt3wi706708f6pHT5IRYVvCSvezcDrDiH1dXYIRk3OG0bowpa_raleptBSlRi 8IU9CGgL_MulLXCkMRALTEzLE6g4cQOBiXh98NnO_Rxadh3RX8rRGUovpmi1ML1EW7uPlrnS9D91 Jcrln5Z_Ca2_XSbuuoVNVlBHsAYwVaS8HnJ8typMoNjGTBESDvpjS6FHzqecIdKio8xgih2_LkUf c1jDW.6BQfqAsT5gHHDQlGsHWJhnltZJz9b8DOOyGqScFIO.DzzfLGnYOF9Re3aMAPucXUft.H4o fLKtiBbKRaGideSH0dENy_LiOYOgzo91RsrMrCaHDnhTf6Bx9GrzoR9In4PZljZWylBfIWA8ryW_ I0o3xr5DFFEoy1d2dwlH2GrTdfy0Z8BjfgU0gz_ZRZF68dsk_M8wJQr3iO0j1DgYRPyXD8UtCEqS 2xe53kVJrBE8QV00lXrYBpFYQRYRVMKKPkmPlrePSkVlqVEW35i91xD_MvKBDYCISUqOnHOPuEoA uzZY5BAUxTywcq3KbO4d99CJcRpOHnrqsBX5AWxOT5fEUro4G3cD0DhYqw9K2kH9U85Wfu1iraR4 uVJ_7fZ09vI0gQfulDI6Ng59z72g7fjER2dBY1WYa57ta26hI73AYf6xj0aU6ZU14oa6_Ome62r5 J8xRw09Dw6ddtO9P2acyJeEgA.0lYNUZGKjM4uk8ckD7ozmzVf5nPfzlHpSo6qrtzIm850NodfrJ 1bRA2tIMdUd3lA_7Sgg7PNipQ.HL6O52_yKyHOUi9Yz3thQp41ekV21RY_4RQsOlnpZZGXRvLhgx l.O0Hk.plhE4GcyXlUTPraupAJRJBrR1FEjlHzoj5IiQ4J1jF3kiHqepLOBOs8fTBgZ80.XwKRPk w22YHWPYUDQ6Bsetb4ZDh4jkNWiDpYEMJ7w.wIeYC6hLJDa7OhEtNuuBWzWuv8FUQniDLF6kYI5b nLXLucRqsTZ.fO9D9FpwUtGqX1HGI.oMiqVF7nt4hUfZl_ypbcnXwyYfEDkaFU99qCa.B3IZxcI2 wYqxhVu0cFd2k_w5FFIykZb4tceOU6WgCeltdzePD7MJ8XRCzC2P3cM953.Jqk9CXvtaf1CVsoE2 vGY_drNAU.IamxBtFU8RXeK.B58AIXqc77Ip_guvShmYwDEKSTg6fpIYZi192lsQfvUqyFY9lTih 9D6PEc.c8ffYFnb0Hf6a2A5Ec10At2630NyqzK8RyZ3b5xm4MmcQZeRQLjezwh5shB_vI4L38QO5 _MtlvdYsqkw3CPMjNCfziNbYVJGptw0UsK6Y0.NiDgy0aPmzd5sqhuB2Vl6Lj_rv0sZTskFt3A3s 2uBYE.pO5NmPvbKz_KEbm3DRlGt8KgB4PfkDXA4UoZu6i9rIeuAj.PWjnx_Jvq.CSBgL164_gEx6 MGelyCRoftmruUwPFUlre479ZaQr54biSYu03DueyYcw677KTDggll9Rscdqhjwz_GrqTU85i6Z_ 2jDdj8a0Ljqvd0z4uPZ6KZBpsvzlC2WjtDGfw1GvXoy4Ca7_ljKdf4ZKIpX3XE3V1xRMQf7zaaLQ .uMrvaClk6rETBV3mmrevKKD.piPzjq7StqW6p6Zf0sLrC2khsTTA1mSDoYSxVZABa.nkxbCTgUU HbwvFJ.dsXYFg9J.0aXM02zFucRjCv5yXXxqbhK5MMv92sqkaUr0IjsRLF7oy4F1jZtzesApOyVt UGY8WeCgMuFPwBGO8Oujuu1A- X-Sonic-MF: X-Sonic-ID: b1d3b0f0-04c5-440e-8774-8f47df05c3fb Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: <309EDCC9-2402-46B5-BDBD-B96677E470DD@apple.com> References: <309EDCC9-2402-46B5-BDBD-B96677E470DD@apple.com> From: Alex Xu To: musl@lists.openwall.com Date: Thu, 06 Jul 2023 08:17:48 -0400 Message-ID: <168864586814.64499.13397704850676744237@alexps.local> User-Agent: alot/0.10 X-Mailer: WebService/1.1.21638 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Subject: Re: [musl] __MUSL__ macro Quoting Alastair Houghton (2023-07-06 06:48:04) > Hi all, >=20 > Before I start, I=E2=80=99m aware of >=20 > >=20 > but I *still* want to add __MUSL__ (see attached patch). >=20 > Let me explain what we=E2=80=99re doing, why we want it and why we think = musl *should* have it. We=E2=80=99re trying to add support for musl to Swi= ft > and its attendant core libr= aries, and there are a number of things about musl that presently differ fr= om other platforms/C libraries we support. All of these seem to fall at least suspiciously closely to "the usage case was badly wrong"... > Examples include the use of `union`s in `pthread_mutex_t` et al (which me= ans that we can=E2=80=99t write a C++ `constexpr` function that returns one= , even if all it does is return `PTHREAD_MUTEX_INITIALIZER`), The issue is that some of the members are volatile, not the union itself. As I understand, though, constexpr is useful to evaluate certain expressions at compile time, such as if (x < 10) or int arr[getlen(x)]. You can't do any arithmetic with pthread_mutex_t, and the only valid value at compile time is PTHREAD_MUTEX_INITIALIZER though, so what is the use case? > the fact that it doesn=E2=80=99t have the `d_namlen` member of `struct di= rent` You can use strlen(d->d_name) instead? This seems like exactly the reason why __MUSL__ should absolutely not be added, because it incentivizes individual checks for endless platforms instead of writing portable code. If strlen(d->d_name) is too slow in some context, then an argument should be made to add d_namlen. glibc even already has a macro _DIRENT_HAVE_D_NAMLEN that could be used to signal support for this rather than hardcoding specific musl versions. > or the fact that `dladdr()` is a no-op when statically linked. When statically linked, the dynamic linking interface doesn't work at all though? And furthermore, even if it did, what would it return? If you're (once again) trying to do stack traces manually, try libunwind? > I=E2=80=99m aware that there are other solutions for some of these cases = - but for instance the `dladdr()` issue is not something you can test at co= nfiguration time when cross-compiling, since there=E2=80=99s no way to know= what the result would be without running a program on the target system (w= hich you don=E2=80=99t necessarily have available at configuration time in = that case). I don't understand, don't you know at compile time whether you're linking statically or dynamically? > Likewise, configuration time tests are slow and aren=E2=80=99t even a th= ing in some of the projects we need to add support in, whereas we do genera= lly have the ability to use the preprocessor. Configure-time checks for specific functionality are a standard part of writing portable C code. Preprocessor checks for specific platforms lead to ifdef swamps that are still not portable to any platforms not initially considered. > You might say we should just bite the bullet and add configuration steps = to all of the other projects, but that is honestly a non-starter; the owner= s of those projects are not likely to accept patches to add such a thing, e= ven as a short-term fix, and the patches to do so would be non-trivial in a= number of cases also. In the longer term we don=E2=80=99t want higher lev= el projects to need to do this kind of thing and the lower level ones could= in many cases do some kind of configuration time testing, but that=E2=80= =99s a longer term goal and it doesn=E2=80=99t help us to add musl support = in the interim, which we would like to do. >=20 > I=E2=80=99ve attached a proposed patch that adds `__MUSL__` (set to the m= ajor version) and `__MUSL_MINOR__` (set to the minor version) as well as `_= _MUSL_PREREQ()` (which works the same way `__GLIBC_PREREQ()` does). In theory, there could possibly be some reason why __MUSL__ could be useful in some cases. However, your examples appear to be exactly why __MUSL__ should not be added because it leads to bad code. Cheers, Alex.