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_INVALID,DKIM_SIGNED, 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 7953 invoked from network); 16 Apr 2022 23:59:41 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 16 Apr 2022 23:59:41 -0000 Received: (qmail 5800 invoked by uid 550); 16 Apr 2022 23:59:38 -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 5768 invoked from network); 16 Apr 2022 23:59:37 -0000 Message-ID: <811c90f8-7ee3-fa86-281d-49c6e3c70400@ludocode.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ludocode.com; s=key1; t=1650153566; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=IkiGImfbulaRDo2OUb6Dh5DqLqbByllQQlmVHvwcJRs=; b=YoRqTHLJOX8yCyrrBzm81ROeESfyfZvX2b9C/nZk7lONu30LvJTejH5ZfKHKUS2pweyQT6 SyBOkgVRs4JOzAhJ75vtBphF4aCZnk60/5owJ3+/G2/juwIkvY9i+dxOqmFfLFGmqm8IyE pquMSO4owMUq3cFjiVKnzzgdXG08WrFyIzSbc0F46TkbBZwsHEEGzeyFxisn2WWZ8UTBkH DE8PqGVQe0ggn/Hkbf9qAIPFKn76F2zr15aDTI1vkKDSQdFov6235/aS8XLSLQ9WpvAyR6 HYkXNl8yl4nXAfsMOzG62y7hom47oMjr+qUeXcLsGRCMJcNdioehfbpHuOG05g== Date: Sat, 16 Apr 2022 19:59:23 -0400 MIME-Version: 1.0 Content-Language: en-US To: musl@lists.openwall.com References: <87a84620-df28-7e62-23e4-57e52bd068af@ludocode.com> <20220416120154.GA2553@voyager> <20220416161626.55aadace.quinq@fifth.space> <94a82803-acf0-4fb7-158b-b13cae530f6c@ludocode.com> <20220416204213.39e4d0e1.quinq@fifth.space> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Nicholas Fraser In-Reply-To: <20220416204213.39e4d0e1.quinq@fifth.space> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: ludocode.com Subject: Re: [musl] Detect qsort_r() support with preprocessor On 2022-04-16 14:42, Quentin Rameau wrote: > > Like I said, I don't control the compiler flags with which my users will > > compile my library. > > You actually do, or at least should. > It's ok to have requirements about a software to work, usually > dependencies, but requiring a standard (as in POSIX) environment is > regular and totally legitimate. > > If your users decide to break your application expectations, then they > must have good reasons for it and should deal with it. But my software doesn't actually have such a requirement in reality. Why should I need to add a requirement about language standards just because you won't give us any in-language way to detect qsort_r()? My users should not need to worry about low-level things like whether they've defined _GNU_SOURCE or _POSIX_C_SOURCE just to use my code. Besides, why do you equate having a requirement with having to configure it manually? Why can't it just detect automatically with the preprocessor whether its requirements are met? Again, no manual configuration is necessary on any other platform. Note that my library doesn't even have qsort_r() as a requirement. I have a fallback but I would prefer to use what's available on the platform. This is why it's especially important for the configuration to be automatic: if the configuration is manual and they don't configure it properly it will still work but with suboptimal code. This is just as error-prone as any of your hypothetical failure cases with __MUSL__. Header-only configure-free libraries are specifically designed not to impose compiler flags or other requirements on their users. That is in fact the whole point, to not force users to build it in a special way and instead let them build it the same way as the rest of their code simply by #including it. For my libraries in particular, I go to great lengths to test that they compile cleanly under a wide variety of compiler flags on many different platforms so that users don't need to think about any of this stuff in order to use the code. > > If I can reliably detect with the preprocessor whether the > > platform has a qsort_r() function > > That is the point, you cannot in the way you're going at it (until > POSIX-next is released). You're confusing theory with practice. Of course I won't be able detect it on some theoretically perfect POSIX libc, but I don't care, because no such libc exists. I care about what works in practice. In practice, I can quite reliably detect qsort_r() with the preprocessor everywhere but musl. musl is certainly not that theoretically perfect POSIX libc by the way. For one thing, you have qsort_r(), and it's under _GNU_SOURCE. Surely you've merged it not for theoretical reasons, but because you actually want people to use it? Nick