Requesting details about making `cpu_set_t` unguarded by `_GNU_SOURCE`

Requesting details about making `cpu_set_t` unguarded by `_GNU_SOURCE`

[bharath appali]

[-- Attachment #1: Type: text/plain, Size: 1219 bytes --]

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.


-With regards,
Bharath Appali

[-- Attachment #2: Type: text/html, Size: 1989 bytes --]

Re: Requesting details about making `cpu_set_t` unguarded by `_GNU_SOURCE`

[Rich Felker]

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