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=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 5784 invoked from network); 7 Jul 2023 07:14:39 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 7 Jul 2023 07:14:39 -0000 Received: (qmail 31783 invoked by uid 550); 7 Jul 2023 07:14:35 -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 31748 invoked from network); 7 Jul 2023 07:14:34 -0000 X-Proofpoint-ORIG-GUID: I2nNajAPny6tuibF3yJ00L7h1Bf5YSin X-Proofpoint-GUID: I2nNajAPny6tuibF3yJ00L7h1Bf5YSin X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.591,18.0.957 definitions=2023-07-07_04:2023-07-06,2023-07-07 signatures=0 X-Proofpoint-Spam-Details: rule=interactive_user_notspam policy=interactive_user score=0 spamscore=0 bulkscore=0 adultscore=0 suspectscore=0 malwarescore=0 mlxscore=0 phishscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2305260000 definitions=main-2307070064 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : content-type : content-transfer-encoding : mime-version : subject : date : references : to : in-reply-to : message-id; s=20180706; bh=yShNQ7uj3dbjXTZpvVwf77jLcG/3fidjYJdKJs9KOWc=; b=L5MyXRsIsCfR7o1A1zktDToAd2aeZZ0+qB+lrP6IUR1qTruAzKPut12TAO01FeFc/nz4 KqODa2zpp+irnRgv42qyr/NEm56YZpqesQ4vROoEbSKjQ7BigZzub6Q95mHsDPm40wyI Fh2oOIMyKZ7p224gjvTGutjGsEXNh972K0IEB+OYMtL28fzQqkw79f643Q4B7f1e/6td Vc43qxU3vuClUBe++NXPBzvqekbDZjLL94Gg62dDPzpaUpTMhZ84h9o+Ky56LS3zsYd0 k1Ml9T6KvpjSASans43tbnsxVAnRUiKnksNreM8wKlVajdNnj27XMssbgr6amruTgweC gw== X-Va-A: X-Va-T-CD: 14dc138f66d48087821ca031f1b11e6a X-Va-E-CD: 56ab0e176e6e23b7c0c7f8bb71e3663a X-Va-R-CD: d86870e6d2b7150a65f5397c4f4f694c X-Va-ID: 4daa7fee-84fe-4983-96dd-633cdb82cdab X-Va-CD: 0 X-V-A: X-V-T-CD: 14dc138f66d48087821ca031f1b11e6a X-V-E-CD: 56ab0e176e6e23b7c0c7f8bb71e3663a X-V-R-CD: d86870e6d2b7150a65f5397c4f4f694c X-V-ID: 5ce9630d-8adf-415a-8a48-81754ae79218 X-V-CD: 0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.591,18.0.957 definitions=2023-07-07_04:2023-07-06,2023-07-07 signatures=0 From: Alastair Houghton Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable MIME-version: 1.0 (Mac OS X Mail 16.0 \(3767.100.2\)) Date: Fri, 07 Jul 2023 08:14:11 +0100 References: <309EDCC9-2402-46B5-BDBD-B96677E470DD@apple.com> <168864586814.64499.13397704850676744237@alexps.local> To: musl@lists.openwall.com In-reply-to: <168864586814.64499.13397704850676744237@alexps.local> Message-id: X-Mailer: Apple Mail (2.3767.100.2) Subject: Re: [musl] __MUSL__ macro On 6 Jul 2023, at 13:17, Alex Xu wrote: >=20 >> Examples include the use of `union`s in `pthread_mutex_t` et al = (which means that we can=E2=80=99t write a C++ `constexpr` function that = returns one, even if all it does is return `PTHREAD_MUTEX_INITIALIZER`), >=20 > The issue is that some of the members are volatile, not the union > itself. ... Arguing about the details of individual issues is an unnecessary = distraction, honestly. They were just OTOH examples of oddities that = we=E2=80=99ve come across so far, and yes, I agree that in some cases = there are potentially better fixes for them than preprocessor = shenanigans - and where those are available I=E2=80=99m totally onboard = with doing that instead, because I *entirely agree* that it=E2=80=99s = better to avoid a huge mass of `#if` conditions in code. There=E2=80=99s = a very good chance that any I add in the various places I might be = interested in adding them will end up being my responsibility to = maintain, so that, if nothing else, is a good motivation for minimising = them. >> or the fact that `dladdr()` is a no-op when statically linked. >=20 > 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? :-D Oh, the irony. One of the places where this behaviour turns out to = be a problem is *in the tests for libunwind*. (That can be solved in = another way without resorting to macros, however.) > I don't understand, don't you know at compile time whether you're > linking statically or dynamically? Not always, no (see situation 2 below). > 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. There are two situations where the lack of macros is absolutely a = problem and there isn=E2=80=99t a sane workaround. 1. You=E2=80=99re cross compiling and the thing you=E2=80=99re = interested in is *runtime* behaviour, so configure-style checks simply = aren=E2=80=99t an option. In a cross-compilation situation the only = thing they can test is that a program will *build*; they can=E2=80=99t = test its behaviour since you don=E2=80=99t necessarily have anywhere to = run it. 2. You=E2=80=99re in a header-only library, particularly one where the = final environment you=E2=80=99re running in wasn=E2=80=99t available at = whatever configuration time you had, assuming you had one at all. A = really good example of this is the built-in headers in Clang or GCC, but = the problem also applies to things like STL or Boost. > On 6 Jul 2023, at 17:26, Szabolcs Nagy wrote: >=20 > the problem is not that the usage is wrong, but that > these can change between different versions of musl > (within abi constraints) and header changes can be > backported by distros. >=20 > so __MUSL__ cannot solve these issues. That=E2=80=99s why `__MUSL__` should evaluate to the major version = number and `__MUSL_MINOR__` to the minor version number, and why we = should have `__MUSL_PREREQ()`, just like Glibc, which, by the way, has = the exact same problems you raise (things can change, and distros can = backport things). If some third-party package wishes to test `__MUSL__`, it=E2=80=99s up = to the maintainers of that package to make sure that they perform = appropriate version checks. And yes, if they=E2=80=99re working around = a bug or musl changes its behaviour to add a feature that wasn=E2=80=99t = there, they may have to update their code from `#ifndef __MUSL__` to = `#if __MUSL_PREREQ(x,y)` or similar. Package maintainers that make = these kinds of tests are used to having to do that and if they=E2=80=99re = willing to accept macro-based tests, then they=E2=80=99ll be well aware = of the cost of doing so. The alternative to adding these isn=E2=80=99t =E2=80=9Clots of non-buggy = support for musl=E2=80=9D. It=E2=80=99s =E2=80=9Cless support for = musl=E2=80=9D, because there are awkward corner cases where it just = isn=E2=80=99t possible to do things any other way. Kind regards, Alastair.