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, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 24312 invoked from network); 17 Apr 2022 02:04:20 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 17 Apr 2022 02:04:20 -0000 Received: (qmail 9279 invoked by uid 550); 17 Apr 2022 02:04:17 -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 9247 invoked from network); 17 Apr 2022 02:04:16 -0000 Date: Sat, 16 Apr 2022 22:04:03 -0400 From: Rich Felker To: Nicholas Fraser Cc: musl@lists.openwall.com Message-ID: <20220417020403.GZ7074@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <94a82803-acf0-4fb7-158b-b13cae530f6c@ludocode.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Detect qsort_r() support with preprocessor On Sat, Apr 16, 2022 at 01:50:06PM -0400, Nicholas Fraser wrote: > On 2022-04-16 08:01, Markus Wichmann wrote: > > > 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). > > All of those other platforms define symbols like __GLIBC__ and __OpenBSD__. Those do not tell you what you want to know: whether a particular interface is supported. They tell you a particular implementation name and version, which then requires you to have massive amounts of hard-coded knowledge about every platform you support, and to fail to support any platform you don't know about. This practice belongs back in the 1980s, not the 2020s. > It's pointless to use a configure script to detect qsort_r() on any other > platform because we can detect it just fine with the preprocessor by using > these symbols. No, it's not. If there were a standard or widely agreed upon macro that indicated "qsort_r is present and has the signature and semantics you expect it to have", that would make it possible to detect. But no such macro exists. I've tried to push forward an effort for defining an analog of the unistd.h macros POSIX defines, but for non-standardized but moderately to widely cross-platform extensions, but nothing has come of that so far. The existing proposal discussion is in the libc-coord list. Until that happens, *detecting* in a configure-style manner is the only way to do this. musl absolutely will not support the practice of hard-coding assumptions about the implementation. > [long rant of wrong stuff I did not read] ... Rich