From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14256 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Requesting details about making `cpu_set_t` unguarded by `_GNU_SOURCE` Date: Mon, 24 Jun 2019 11:57:06 -0400 Message-ID: <20190624155706.GA1506@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="207558"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-14272-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jun 24 17:57:22 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hfRLO-000rue-H1 for gllmg-musl@m.gmane.org; Mon, 24 Jun 2019 17:57:22 +0200 Original-Received: (qmail 17758 invoked by uid 550); 24 Jun 2019 15:57:20 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 17740 invoked from network); 24 Jun 2019 15:57:19 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14256 Archived-At: On Mon, Jun 24, 2019 at 02:41:16PM +0530, bharath appali wrote: > Hi I'm trying to port some of my programs from glibc to MUSL libc, and i > have faced problems with `cpu_set_t` struct (I was required to add > `_GNU_SOURCE` definition to work on MUSL). > > In glibc i see that the struct `cpu_set_t` is not dependent on > `_GNU_SOURCE` or `_USE_GNU` > > on glibc 2.17 : > > ``` > Name : glibc > Arch : i686 > Version : 2.17 > ``` > > bits/sched.h:125 (on glibc): > > ``` > /* Data structure to describe CPU mask. */ > typedef struct > { > __cpu_mask __bits[__CPU_SETSIZE / __NCPUBITS]; > } cpu_set_t; > > ``` > > Here `cpu_set_t` is not dependent on `_USE_GNU`(_GNU_SOURCE) > > sched.h:79 (on musl) : > > ``` > #ifdef _GNU_SOURCE > #define CSIGNAL 0x000000ff > .. > .. > .. > #define CLONE_IO 0x80000000 > int clone (int (*)(void *), void *, int, void *, ...); > .. > .. > .. > void free(void *); > > > > typedef struct cpu_set_t { unsigned long __bits[128/sizeof(long)]; } > cpu_set_t; > > ``` > > Here `cpu_set_t` is exposed only if its defined `_GNU_SOURCE` > > I would like to know if there are any challenges to expose `cpu_set_t` > irrespective of `_GNU_SOURCE` definition. > > If its possible to define `cpu_set_t` by default(independent of > `_GNU_SOURCE`), It will be helpful to have compatibility with glibc. This looks like a bug, or at least unintended behavior, in glibc. Normally they make an effort not to pollute the namespace in nominally standards-conforming profiles, even when it means omitting things like MAP_ANON that "should have" always been exposed and that are included for future versions of the standard. I suspect in the mess of splitting it between the main sched.h and bits headers they just missed the feature test macro check. Strictly speaking, there is a global reservation made on *_t by POSIX, but it's "controversial" since everybody violates it in their application code by defining their own "_t" types. So, again strictly speaking, it's not non-conforming to expose it, but it's contrary to general policy of both glibc and musl. Note that all the macros to actually make use of a cpu_set_t are guarded by _GNU_SOURCE, so most applications using it will be doing the right thing already and declaring their intent with _GNU_SOURCE. In light of all that, my leaning is not to change this. Rich