From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 32381 invoked from network); 6 Dec 2020 17:32:49 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 6 Dec 2020 17:32:49 -0000 Received: (qmail 21977 invoked by uid 550); 6 Dec 2020 17:32:47 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 21957 invoked from network); 6 Dec 2020 17:32:46 -0000 Date: Sun, 6 Dec 2020 18:32:34 +0100 From: Szabolcs Nagy To: Rich Felker Cc: Ariadne Conill , musl@lists.openwall.com, Drew DeVault Message-ID: <20201206173234.GT1370092@port70.net> Mail-Followup-To: Rich Felker , Ariadne Conill , musl@lists.openwall.com, Drew DeVault References: <3879728.LAGH0JGj17@nanabozho> <20201206170647.GF534@brightrain.aerifal.cx> <2178772.BdMzd0Z1jD@nanabozho> <20201206171930.GG534@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201206171930.GG534@brightrain.aerifal.cx> Subject: Re: [musl] [PATCH v2] riscv64: correct struct __ucontext name * Rich Felker [2020-12-06 12:19:30 -0500]: > On Sun, Dec 06, 2020 at 05:10:25PM +0000, Ariadne Conill wrote: > > Bummer. In that case, I suggest musl use the same struct tag consistently. It > > should probably be struct ucontext_t for consistency with glibc. > > I don't recall the original reason it was inconsitent with glibc here. glibc changed the declaration 3 years ago (breaking c++ abi) before that it was not posix conform so musl could not be consistent with it. see "Rename struct ucontext tag" in https://sourceware.org/bugzilla/show_bug.cgi?id=21457 > Note that signal.h has (which is probably wrong and should be > removed): > > #ifdef _GNU_SOURCE > #define __ucontext ucontext > #endif > > so that the tag gets renamed if _GNU_SOURCE is defined. Maybe at one > point glibc called it "struct ucontext", which was a namespace > violation since it's not in a reserved namespace, and we used > __ucontext to get the freedom to rename it and expose that only in a > _GNU_SOURCE context. > > Whatever the reason, though, the struct tags is C++ABI and should not > be changed. The rv64 inconsitency was unintentional and hopefully is > not yet widely used enough for anyone to care that it's being fixed > now (in theory could mess up linking C++ libs with ucontext_t in their > public interface surface). > > Note that none of this is visible to applications that aren't doing > anything horribly wrong. Neither "struct ucontext_t" nor "struct > __ucontext" (nor "struct ucontext", which it looks like we were > wrongly trying to support) is API. > > Rich