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.3 required=5.0 tests=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 19720 invoked from network); 19 Apr 2022 13:32:27 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 19 Apr 2022 13:32:27 -0000 Received: (qmail 5143 invoked by uid 550); 19 Apr 2022 13:32:24 -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 4087 invoked from network); 19 Apr 2022 13:32:24 -0000 Date: Tue, 19 Apr 2022 09:32:12 -0400 From: Rich Felker To: Nicholas Fraser Cc: musl@lists.openwall.com Message-ID: <20220419133211.GA7074@brightrain.aerifal.cx> References: <87a84620-df28-7e62-23e4-57e52bd068af@ludocode.com> <20220416120154.GA2553@voyager> <20220416161626.55aadace.quinq@fifth.space> <94a82803-acf0-4fb7-158b-b13cae530f6c@ludocode.com> <20220417020403.GZ7074@brightrain.aerifal.cx> <823acf0f-461d-d599-feb7-e0e21cfeb51d@ludocode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <823acf0f-461d-d599-feb7-e0e21cfeb51d@ludocode.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Detect qsort_r() support with preprocessor On Mon, Apr 18, 2022 at 11:38:49PM -0400, Nicholas Fraser wrote: > Just to recap: I'm writing a header-only library. My intention is for users to > just put the headers on their include path and use it, no configuration needed. > I'd like to use any variation of qsort_r()/qsort_s() that's available on the > platform. > > GNU/musl/POSIX-next qsort_r() and C11 Annex K qsort_s() are virtually the > same; Free/Net/DragonFlyBSD and Apple qsort_r() are the same; and Windows > qsort_s() is the outlier. There are only three possible prototypes so it's > trivial for my code to permute the arguments to match what's available. All I > need to do is detect which one the platform has. This would be a great usage case for the "Macro-based advertisement of libc extensions" proposal on libc-coord. The right thing to do here is to try to move that forward, explaining how it solves your problem. I'll try to revitalize that. > In cases where the headers declare it conditionally, I simply declare it myself > so that my users don't need to define _GNU_SOURCE or __STDC_WANT_LIB_EXT1__ or > whatever: You cannot #define _GNU_SOURCE or __STDC_WANT_LIB_EXT1__ after any standard header has already been included. The only place they can safely be defined is at the top of the source file before any headers, or on the command line with -D. There are two reasons for this: one is that the rules say so (both POSIX and glibc document this, in addition to musl). The other more mechanical reason is that the header you're trying to get the definitions from might already have been included (directly or indirectly) earlier, whereby the multiple-inclusion guard prevents it from exposing anything else the second time it's included. This extends to the case where the FTMs are actually processed by a unified file (like features.h) into internal-use-only macros on the first inclusion of any standard heaader. For this reason, it's possible that even headers which weren't already included once will still fail to see the updated FTMs. So, defining these from a header-only library is an on-starter unless you impose a requirement on the caller that they must include your header absolute-first (and then they can only use one such header-only library). An approach that actually works is just documenting that the caller must ensure they're defined appropriately for features they want your library to be able to use. Or, just being compatible with whatever choice the caller made (so using your own fallback or whatever if it's not exposed). Rich