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=0.1 required=5.0 tests=BULK_RE_SUSP_NTLD,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FROM_SUSPICIOUS_NTLD,MAILING_LIST_MULTI, PDS_OTHER_BAD_TLD,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 32653 invoked from network); 16 Apr 2022 18:42:32 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 16 Apr 2022 18:42:32 -0000 Received: (qmail 18141 invoked by uid 550); 16 Apr 2022 18:42:29 -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 18097 invoked from network); 16 Apr 2022 18:42:29 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=fifth.space; h=date:from :to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=20190812; bh=3AERe92y VF/l4YIm1SMXOVeiEW8=; b=Gas7TZpLDEVoH6hTq3VklT39/ERn7ywnQNZFPQPH v2EMzMIwLQKIeYzSoBfV0HPihe+RLctQ9Iw83nK19HVF/QE3/TL5m+ngnouNeqR7 Za2G7Ywm2dq/v4Xpj6fnoVkkhegVzEjWh4FEhGbgmWM1SwT0tDMyLOojXEEflQVV EXoq1jtQsoSyRKlEkreW4SMscgIMOPhggPFYyrqlyyyVLHq55ZesOYje60AtZT8f ANT3cLkqdoC/oKi1bd6X49b9S9Yc2mXruAVRkmfut+pjAjj0T8cpaiGroErffxOK 1glu4ng7UBqwLMIHJy0Q+aKnz3Tjf5VyUt0fEA00UBFyzA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=fifth.space; h=date:from:to :subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=20190812; b=Fu 87AxY7PrHv+aLvTsFlXpXvM421Hk1ixwkZ5ZFUB8C+qubloME1KTvqsDNx989zJN 1YQZGRehbJPloWz4qioJlBlE743v1bFAqycnnHC7GlgUY8Cn/v6IulhpxagiB8jc TZ4wH2HRUwyWOmlZJZ4aDPPRFpZ1WXTb07pWyiiW//7J2byoelU7leS3YXaq8tvY ShpIWuGmNUkqxnme9pOq1xCPGMhymy1skPXYyQ4zFv8JGMYzV/euhpWqxT9Q7Ysz fkZ+AJ0d8eV1eSCds319NTiIYvSVR1ghI+bVBB/2nJSHCztnZhzYJIv2fjx0NYFk JJYfD4ZcZXtU9QgcrWeA== Date: Sat, 16 Apr 2022 20:42:13 +0200 From: Quentin Rameau To: musl@lists.openwall.com Message-ID: <20220416204213.39e4d0e1.quinq@fifth.space> In-Reply-To: <94a82803-acf0-4fb7-158b-b13cae530f6c@ludocode.com> 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-Transfer-Encoding: 7bit Subject: Re: [musl] Detect qsort_r() support with preprocessor Hi Nicholas, > On 2022-04-16 10:16, Quentin Rameau wrote: > > Just as a note, qsort_r() has indeed been added to POSIX-next, so you'd > > only need to ask for _POSIX_C_SOURCE with a value of 20XXXX, when it's > > actually been released. > > Well that doesn't help me today. But even if it did, GCC and Clang don't define > _POSIX_C_SOURCE automatically. Under glibc it's only defined under -std=gnu*, > not -std=c*, and under musl (Alpine) it doesn't appear to be defined either > way. Indeed, that isn't something that the compiler should define for the application, it's for the application to request it. > 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. > 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).