From: Ariadne Conill <ariadne@dereferenced.org>
To: Szabolcs Nagy <nsz@port70.net>, musl@lists.openwall.com
Cc: musl@lists.openwall.com, Drew DeVault <sir@cmpwn.com>
Subject: Re: [musl] [PATCH v2] riscv64: correct struct __ucontext name
Date: Sun, 06 Dec 2020 16:55:39 GMT [thread overview]
Message-ID: <3879728.LAGH0JGj17@nanabozho> (raw)
In-Reply-To: <C7LPPDEK9MIU.2E0M7RCVVZ08V@taiga>
Hello,
On Sunday, December 6, 2020 5:49:25 AM MST Drew DeVault wrote:
> On Sun Dec 6, 2020 at 3:51 AM EST, Szabolcs Nagy wrote:
> > * Drew DeVault <sir@cmpwn.com> [2020-12-05 18:10:06 +0000]:
> > > This makes it consistent with other architectures and fixes some issues
> > > with downstream software.
> >
> > which software?
> >
> > glibc uses struct ucontext_t too and user code should use ucontext_t
> > without struct.
Some glibc architecture ports use the struct __ucontext and even struct
ucontext names, or at least did in the past.
> libucontext, which does use ucontext_t.
>
> In fact, the issue was more related to the type conflict with
> ucontext.h, which declared struct __ucontext in the scope of its
> function declarations due to the naming mismatch.
glibc uses the POSIX 2004 standardized ucontext_t type in its public
definitions. I believe musl should do the same.
As far as libucontext goes, this is increasingly moot because 0.13 will
introduce freestanding mode which avoids the musl definitions entirely, instead
using simplified (though ABI compatible) definitions, allowing it to not only be
used on musl but on other libc and other OS entirely (for example, it is known
to now build on AmigaOS and Darwin).
libucontext using its own definitions is an important step toward eventually
taking ucontext.h out of musl entirely, and providing it in libucontext
instead, too, which I think musl should do since the ucontext API was dropped
from POSIX.
But right now, I think the best way forward is to leave the architecture
headers alone and just fix the ucontext.h definitions instead. I can send a
patch doing that if you want to focus on other things.
Ariadne
next prev parent reply other threads:[~2020-12-06 16:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-05 18:10 Drew DeVault
2020-12-06 8:51 ` Szabolcs Nagy
2020-12-06 12:49 ` Drew DeVault
2020-12-06 16:55 ` Ariadne Conill [this message]
2020-12-06 17:06 ` Rich Felker
2020-12-06 17:10 ` Ariadne Conill
2020-12-06 17:19 ` Rich Felker
2020-12-06 17:32 ` Szabolcs Nagy
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=3879728.LAGH0JGj17@nanabozho \
--to=ariadne@dereferenced.org \
--cc=musl@lists.openwall.com \
--cc=nsz@port70.net \
--cc=sir@cmpwn.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).