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, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 14651 invoked from network); 16 Apr 2022 12:02:11 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 16 Apr 2022 12:02:11 -0000 Received: (qmail 10107 invoked by uid 550); 16 Apr 2022 12:02:08 -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 10075 invoked from network); 16 Apr 2022 12:02:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1650110516; bh=PnIP9MGGuttGaAdHLv9He6S5W6tbM0RS+W3pBcZ43ic=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=JS2GrMXJKVJXnoqCJzLNjBkEMJdAySGlWG5z4x2DkzPD8GfmTmlqVKznCYaOp6Ylb J8ZTyjBuiV9dPX9iJyoVNQMk5tDuyr+dxge0uuh6fL6po7yOSOJuwL1ay9xWrY7jCj afdPu8CLiGCIRQbBcs9SiIrukGDxxEHIvm8ONURU= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Date: Sat, 16 Apr 2022 14:01:54 +0200 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: <20220416120154.GA2553@voyager> References: <87a84620-df28-7e62-23e4-57e52bd068af@ludocode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87a84620-df28-7e62-23e4-57e52bd068af@ludocode.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-Provags-ID: V03:K1:iUxAqnlC0ii2Nr7EcaiRBy8eao4U/LzFokFKRr9VWuYLxhGAt7t b/uPXYM1cTxuZcTPI7dD8dyRGgogd3NOF+LY3h3VxoDjhnvhY19jNKweHg9OX2szqz0q2jz t132Iyz/dfOhq0qS8t8wFcWBGO+jpACwaBR+i+248DzF8lQn8GrqARcvNyO4sxVR5yj3FdN 1kJ48UTD0oXqMM1UzdlpQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:DuPRWC67H8M=:r8hcdFJp8cUfcTE4M1v5Gv MpbZHDgzFZS7sxqwLEd3b4zB2pNdVxsjhNWbr/DSd4SJAkFbjwP1QP4YHo/iK2CQzbn4tpko8 bq5c2sOJIe5G0FsM3d/pGmAaxMlBs27DwwqzClAmQnDsDlJtV0Gr+KNk2jr02+75b8bOWQMlL ZIrNATQJOYyONa4bBkt4pAQHhenKzFvzTYcZKdlOZ0xEn0cnBcj6TXG7hcCEk8Y+Du+8SRMNg Ca9hJgWozYPZOFkm5ut4JmiusVniR6ipyVu4h7S+9lNnvNcTAD4rOAIxPErmvCs7xOOvWd268 C1GklqY9okb1WXFt+o1n+mw0ACZkb7QB6x0jbgm6NawrsOWokmyyOOOiF8KBpEmr2ZPmQj0x+ RJMao9Miwjo+m8d1XM1hlJIE20M70Oab0ZFlDDq8Wjri7dZGPDu8decvg39+q++kkayaxwH6P Rly+AkZ0N6HJsrVDYC69cW1RK1gtluw2+v9+X8VlmTUw/AtFEihNnQWg9nOd7fWnEA7WtWuw/ 6msOvHlspOKkD8xF3Go5Sb+4glhp7eYX6Wgz5ZQfhtBDb1a/Os9A6t5yjZqxFvQ6u/oPhviC1 MpYAFnIwh8Xxj/J1ex5RnneoZddgUYCj9nigltPiUK2UVMsg9DxGzP+O2ugA6LdAlvh2eQhnr jutPhN+OMWt99SpwFJHFfcfGu7HXUNImlIG+TtBNQrBbv4yj2kdIV/PigCcBk4lKphY1+Fffl 4/A/Kw6ldGTObF9RiBbcKrWLkWp2yLpJ7LuEWYx0/g3AmYdcpl4GAYmgqLePBpS5rwMIQoXA6 tC/9jyfwdGLzPdaXcYCgB0e9fLfLxhRjFLrvswhb3RrrUiLR6a8DnCbWtyNsCm6Rr3hgSH6X0 Q+nt8aL72do2tcdUFmK7rE0u3hyY3dnV/uWyTiX/qaOj9DJZdbWzHVo7lQbCKizziKt4ZbBBH xVHTr3bhkqARf/euGfz9w0K9Rt1acE/VvlBdii6rG3I+aEGdwRDqgRKn/jv9JzMj/7Q29drno BM5pyfQAcrvwQ2AB81UxuUhN/FWzIUHKBBNHPjomin4RKHCy2of02UWu5fCNugSKNFvz3TO1H /rKIyc6VGdmPks= Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] Detect qsort_r() support with preprocessor On Sat, Apr 16, 2022 at 04:13:56AM -0400, Nicholas Fraser wrote: > Hello musl devs, > > qsort_r() has been added to musl 1.2.3 and it has been backported to > the previous version of musl in Alpine. How can I detect whether this > function is available using the preprocessor? > > The community wiki advocates "testing" for feature support, which I > guess means compiling a test program like an autotools configure > script. Guess why that is. It is more portable to do that way than to define new non-standard macros. The only macros musl will define are standard ones. > Can we not just test for a macro instead? Have you considered > defining something like `__HAS_QSORT_R` to tell us directly that you > support it? > Unless qsort_r() were part of a new release of POSIX (then you could look at _POSIX_VERSION), or a member of an option group (then you could look at the option group macro), not really. If musl had a bespoke symbol, it would just diverge. Then musl would have its macro, glibc another one, OpenBSD would do a totally different thing again, and in the end you get a leaning tower of hostname (look it up). Plus, adding such a symbol would then basically mean it could never be retracted again. Keep going in that direction for a decade and you get a mess of non-standard symbols to keep track of. > I am writing a cross-platform header-only library. I want my users to > be able to just drop the header files of my library into their > codebase. I really don't want them to have to write their own > configure tests just to tell my library whether musl provides > qsort_r(). It's not supposed to be just for musl. Doing a configure test would correctly detect it in all configurations. Why not have a "config.h", containing all the switches? If set wrong, it just won't compile. If set right, it will compile on platforms you never even heard of. In case of pure computations like qsort_r(), there is also the possibility of the client code remedying a lacking implementation by providing the extension itself, which a version based approach will not detect correctly. > I am able to detect variants of qsort_r() or qsort_s() with > the preprocessor on all other platforms that support such an > extension. I highly doubt glibc for example provides a special symbol for qsort_r() alone, so I am guessing you are querying version numbers. Which of course fails in the face of backporting, and in case of new implementations. Whereas just writing a compile test will not. Ciao, Markus