From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11594 invoked by alias); 5 Jun 2014 02:54:00 -0000 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 Received: (qmail 11578 invoked by uid 89); 5 Jun 2014 02:53:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mtaout23.012.net.il Received: from mtaout23.012.net.il (HELO mtaout23.012.net.il) (80.179.55.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 05 Jun 2014 02:53:56 +0000 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0N6O00B00CEGNZ00@a-mtaout23.012.net.il> for gdb-patches@sourceware.org; Thu, 05 Jun 2014 05:53:53 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N6O00BJ3DDTLX90@a-mtaout23.012.net.il>; Thu, 05 Jun 2014 05:53:53 +0300 (IDT) Date: Thu, 05 Jun 2014 02:54:00 -0000 From: Eli Zaretskii Subject: Re: [PATCH 2/2 v3] Demangler crash handler In-reply-to: To: Doug Evans Cc: gbenson@redhat.com, gdb-patches@sourceware.org, aburgess@broadcom.com, fw@deneb.enyo.de, mark.kettenis@xs4all.nl, palves@redhat.com, tromey@redhat.com Reply-to: Eli Zaretskii Message-id: <8338fk6p8p.fsf@gnu.org> References: <20140604100755.GA7570@blade.nx> <20140604100957.GC7570@blade.nx> <834n017z8w.fsf@gnu.org> <20140604133603.GC10121@blade.nx> <83sink7pww.fsf@gnu.org> <20140604142844.GB11730@blade.nx> <20140604182529.GA14897@blade.nx> X-IsSubscribed: yes X-SW-Source: 2014-06/txt/msg00228.txt.bz2 > Date: Wed, 4 Jun 2014 18:11:16 -0700 > From: Doug Evans > Cc: Eli Zaretskii , "gdb-patches@sourceware.org" , > Andrew Burgess , Florian Weimer , > Mark Kettenis , Pedro Alves , > Tom Tromey > > One thing that I think should be considered is that we'll go from the > simple state of "just ifdef every signal" in places like > common/signals.c to having some signals you are required to not ifdef > and some you do, and needing to know which category every signal fits > in. I don't have a strong opinion, but I'm ok with the status quo. The list of ANSI-standard signals is short, and it's easy to check which signal is or isn't. Ifdef's are ugly. Minimizing their use is a Good Thing.