From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87050 invoked by alias); 2 May 2017 15:53:57 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 87027 invoked by uid 89); 2 May 2017 15:53:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy=Hx-languages-length:1490, reserved, claim, expecting X-HELO: relay1.mentorg.com Date: Tue, 02 May 2017 15:53:00 -0000 From: Joseph Myers To: Zack Weinberg CC: GNU C Library Subject: Re: RFC: fixing signal context namespace issues In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-SW-Source: 2017-05/txt/msg00032.txt.bz2 On Tue, 2 May 2017, Zack Weinberg wrote: > > Note the caveats on platforms using "typedef struct sigcontext > > mcontext_t;": (a) as sigcontext is not a reserved name, the C++ mangled > > name of mcontext_t would change depending on __USE_MISC, > > ... that sounds like an unacceptable side effect to me. I would make > the strong claim that the C++ mangled name of a type must never change > in response to any user-controlled feature-selection macro, except > those that have the specific function of selecting alternative > definitions of a particular type (e.g. __USE_FILE_OFFSET64). Well, an alternative would be to stop including bits/sigcontext.h from sys/ucontext.h (absent __USE_MISC, anyway; the inclusion directly from signal.h is already conditional on __USE_MISC), and duplicate the definition directly in sys/ucontext.h (with or without having the use of __ prefixes on field names conditional on !__USE_MISC), so: typedef struct { ... } mcontext_t; That would change the mangled name (from "sigcontext" to "mcontext_t"), but as an unconditional one-off change (like that when we eliminated the "struct siginfo" name some time ago) rather than depending on feature test macros. Of course that would break things for anyone expecting mcontext_t and struct sigcontext to be the same type, but as they aren't the same type on x86 I doubt people are depending on equality elsewhere. -- Joseph S. Myers joseph@codesourcery.com