From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4924 invoked by alias); 10 Feb 2010 08:19:05 -0000 Received: (qmail 4912 invoked by uid 22791); 10 Feb 2010 08:19:04 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 10 Feb 2010 08:19:00 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 40CB12BAB91; Wed, 10 Feb 2010 03:18:58 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id NOVsA7UfzTJK; Wed, 10 Feb 2010 03:18:58 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 9FC322BAB97; Wed, 10 Feb 2010 03:18:57 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 2B10CF59A2; Wed, 10 Feb 2010 12:18:50 +0400 (RET) Date: Wed, 10 Feb 2010 08:19:00 -0000 From: Joel Brobecker To: Chris Moller Cc: tromey@redhat.com, gdb-patches@sourceware.org Subject: Re: PR11067 patch Message-ID: <20100210081850.GA2907@adacore.com> References: <4B6D70A3.2090208@redhat.com> <4B719BF6.1040207@redhat.com> <4B722202.5010506@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B722202.5010506@redhat.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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: 2010-02/txt/msg00269.txt.bz2 > But what's the cost? Functionally, it consists mostly of replacing > an fputs_filtered with a vfprintf_filtered, so the performance hit > is negligible, and the patch adds maybe a hundred lines of code, > most of it in setting up the set enum-fmt command and translating > the format strings. One lesson we (AdaCore) learnt from developping GPS (AdaCore's IDE), is that adding options and flexibility can quickly cause the amount of testing to explode. I agree with Tom in this case that it's better to not have the formatting option. I know it can be discouraging sometimes that everyone bikesheds a bit on things that small. I actually think it's a good thing that people provide their opinions, even at the risk of mild bikeshedding. I'd rather have all opinions now rather than later. But there comes a point when we need to make a decision, and I think we have reached that point (or went past it? ;-) ). I personally like Pedro's suggestion, but I'm ready to accept any format at all. I don't think anyone really expressed a strong disagreement, so I'd just review the thread, select the format that seemed to be prefered based on feedback, and just announce that this is what you'll implement. I'm sure some will feel like they must propose something that's obviously nicer than your proposal, but if there are no objection, I suggest we go with what you announced in the end. -- Joel