[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190624155706.GA1506@brightrain.aerifal.cx>
Date: Mon, 24 Jun 2019 11:57:06 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Requesting details about making `cpu_set_t` unguarded by
`_GNU_SOURCE`
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
