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 494 invoked from network); 28 Sep 2021 12:39:20 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 28 Sep 2021 12:39:20 -0000 Received: (qmail 1125 invoked by uid 550); 28 Sep 2021 12:39: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 1107 invoked from network); 28 Sep 2021 12:39:16 -0000 Date: Tue, 28 Sep 2021 08:39:02 -0400 From: Rich Felker To: Quentin Rameau Cc: musl@lists.openwall.com Message-ID: <20210928123902.GB4428@brightrain.aerifal.cx> References: <20210927233515.GA4428@brightrain.aerifal.cx> <20210928072005.477eea59@tpx.quinq.eu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210928072005.477eea59@tpx.quinq.eu.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Promoting extension functions up from _GNU_SOURCE ? On Tue, Sep 28, 2021 at 07:20:05AM +0200, Quentin Rameau wrote: > Hi Rich, > > > For the ones that are POSIX-future, we could go ahead and move them to > > baseline _POSIX_C_SOURCE, or wait a bit. > > What's baseline? Is that 200809L? Yes. > Those POSIX-next functions shouldn't be exposed under 200809L anyway, > but under 202XXXL (whatever is decided at release), should they? The only officially-supported is "latest". Up til now that's meant 2008 (+TCs) only, but my original intent was always that it be moving with the standard. We generally don't have different version handling unless there were interfaces *removed* in the new version (like gethostby* etc.), which are still exposed under the old version. If there's a reason this doesn't make sense in the future, it can be reviewed. But if multiple versions are to be 'supported' in any nontrivial sense (even complex header logic) there should be compelling reasons to believe just having the new versions would break things, not just a box-checking exercise.