From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3269 invoked by alias); 31 Dec 2008 03:57:59 -0000 Received: (qmail 3257 invoked by uid 22791); 31 Dec 2008 03:57:58 -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, 31 Dec 2008 03:57:17 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 4E4522A9691; Tue, 30 Dec 2008 22:57:15 -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 j-n0t40u1RUI; Tue, 30 Dec 2008 22:57:15 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 7FFE92A968F; Tue, 30 Dec 2008 22:57:14 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 10038E7ACD; Wed, 31 Dec 2008 07:57:06 +0400 (RET) Date: Wed, 31 Dec 2008 03:57:00 -0000 From: Joel Brobecker To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: PR7580 - Command to force abort when internal error Message-ID: <20081231035705.GA31595@adacore.com> References: <200812290335.09199.pedro@codesourcery.com> <20081229044011.GH4216@adacore.com> <200812291426.59784.pedro@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200812291426.59784.pedro@codesourcery.com> User-Agent: Mutt/1.4.2.2i 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: 2008-12/txt/msg00468.txt.bz2 > I looked around for other three-state commands, and didn't find > reusable patterns, which made me drop the idea of > generalizing this, but there's a chance I didn't look right. I couldn't come up with other examples where this would be useful either. But it's always easy to factorize it if we find some later. > I think the best is to make this an enum command with > the three options ask|on|off, or perhaps better yet, ask|yes|no, as > attached? Sounds good to me. > (set_internal_problem_cmd, show_internal_problem_cmd): New dummy > functions. > (add_internal_problem_command): New. > (_initialize_utils): New. Just to be consistent: We try to add a short description as a comment for all new functions introduced. I think it's OK to lose the comment in the case of the dummy functions, but it'd be nice to have a small description for add_internal_problem_command... Other than this nit picking, the patch looked OK to me. -- Joel