From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: Requesting details about making `cpu_set_t` unguarded by `_GNU_SOURCE`
Date: Mon, 24 Jun 2019 11:57:06 -0400 [thread overview]
Message-ID: <20190624155706.GA1506@brightrain.aerifal.cx> (raw)
In-Reply-To: <CAKwRgPVSNuqiGo9MghzhWLyg8w-Y2R0EfuaU=1S3cAKTaDvTBw@mail.gmail.com>
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
prev parent reply other threads:[~2019-06-24 15:57 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-24 9:11 bharath appali
2019-06-24 15:57 ` Rich Felker [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190624155706.GA1506@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).