From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4454 invoked by alias); 13 Jan 2009 19:19:27 -0000 Received: (qmail 4446 invoked by uid 22791); 13 Jan 2009 19:19:27 -0000 X-SWARE-Spam-Status: No, hits=-0.4 required=5.0 tests=AWL,BARRACUDA_BRBL,BAYES_00,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout7.012.net.il (HELO mtaout7.012.net.il) (84.95.2.19) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 13 Jan 2009 19:18:40 +0000 Received: from conversion-daemon.i-mtaout7.012.net.il by i-mtaout7.012.net.il (HyperSendmail v2007.08) id <0KDF00F00AED1B00@i-mtaout7.012.net.il> for gdb-patches@sourceware.org; Tue, 13 Jan 2009 21:18:18 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.126.230.7]) by i-mtaout7.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KDF00HKJCAD6NF0@i-mtaout7.012.net.il>; Tue, 13 Jan 2009 21:18:14 +0200 (IST) Date: Tue, 13 Jan 2009 19:19:00 -0000 From: Eli Zaretskii Subject: Re: [0/2] Inspect extra signal information In-reply-to: <200901131850.01687.pedro@codesourcery.com> To: Pedro Alves Cc: gdb-patches@sourceware.org, mark.kettenis@xs4all.nl Reply-to: Eli Zaretskii Message-id: References: <200901121846.51709.pedro@codesourcery.com> <200901131105.34822.pedro@codesourcery.com> <200901131850.01687.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-01/txt/msg00295.txt.bz2 > From: Pedro Alves > Date: Tue, 13 Jan 2009 18:50:01 +0000 > Cc: mark.kettenis@xs4all.nl > > > I happen to agree with Mark. Not only we don't need to use symbols > > with leading underscores, it's actually forbidden by the C Standard > > (AFAIK). Such names are "reserved for the implementation" of the C > > language, which we aren't. > > > > I don't think that argument fits this case, because, well, this > is really a kernel data type, which can use it's own rules. There's no > way for this $_siginfo type to collide with anything in the user code. The problem is not to clash with GDB code elsewhere, the problem is the possibility of a clash with the library. A library implementation is free to change the symbol it uses for this any time, and use the __uid_t one for something utterly incompatible. Since the name begins with 2 underscores, the library implementation doesn't need to bother being back-compatible, because such names are off-limits for user code. > Also, these are also the types you'd see if I wasn't synthesizing > it, but using the debug info instead, in case it is available --- I > was actually doing that in a previous version of the patch, and > synthesized the type only as a fallback, but, then considered that > if we're synthesizing sometimes, might as well make it simpler and > always synthesize -- less cases, less bugs, less maintenance. Sorry, I don't follow: what do you mean by ``synthesizing''?