From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 54877 invoked by alias); 24 Jun 2018 18:43:58 -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 54858 invoked by uid 89); 24 Jun 2018 18:43:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=H*M:193, Hx-languages-length:854 X-HELO: mailsec106.isp.belgacom.be Received: from mailsec106.isp.belgacom.be (HELO mailsec106.isp.belgacom.be) (195.238.20.102) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 24 Jun 2018 18:43:57 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2BJBgDv5S9b/+ApQFdcHAEBAQQBAQoBA?= =?us-ascii?q?YNJgU8Sg1pHiGSNZTEBkCyGJgsrAYMsgRQCgwIiOBQBAgEBAQEBAQIBbCiCNSQ?= =?us-ascii?q?Bgk8BBSMzMwgDDgoCAiYCAjkeBgGFO6xQghyEXINlgQKBC4k3P4Qeh3uCVQKMR?= =?us-ascii?q?4xoBwKBa40mjUkrkUKBWCGBUm2DPZBSPYE9CAwBjUcBAQ?= X-IPAS-Result: =?us-ascii?q?A2BJBgDv5S9b/+ApQFdcHAEBAQQBAQoBAYNJgU8Sg1pHiGS?= =?us-ascii?q?NZTEBkCyGJgsrAYMsgRQCgwIiOBQBAgEBAQEBAQIBbCiCNSQBgk8BBSMzMwgDD?= =?us-ascii?q?goCAiYCAjkeBgGFO6xQghyEXINlgQKBC4k3P4Qeh3uCVQKMR4xoBwKBa40mjUk?= =?us-ascii?q?rkUKBWCGBUm2DPZBSPYE9CAwBjUcBAQ?= Received: from 224.41-64-87.adsl-dyn.isp.belgacom.be (HELO md) ([87.64.41.224]) by relay.skynet.be with ESMTP/TLS/AES256-GCM-SHA384; 24 Jun 2018 20:43:55 +0200 Message-ID: <1529865834.2365.193.camel@skynet.be> Subject: Re: [RFA_v2 1/8] Add helper functions check_for_flags and check_for_flags_vqcs From: Philippe Waroquiers To: Pedro Alves , gdb-patches@sourceware.org Date: Sun, 24 Jun 2018 18:43:00 -0000 In-Reply-To: <0ca18b5e-2b28-f33f-b547-027e00ed17ed@redhat.com> References: <20180605204905.30612-1-philippe.waroquiers@skynet.be> <20180605204905.30612-2-philippe.waroquiers@skynet.be> <1529012414.2365.9.camel@skynet.be> <0ca18b5e-2b28-f33f-b547-027e00ed17ed@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-06/txt/msg00568.txt.bz2 On Fri, 2018-06-15 at 17:24 +0100, Pedro Alves wrote: > Yeah, on second thought I think using "flags" for the function is > fine since it only handles flag-like options. On my option-revamping > prototype I was calling those kind of options "switches" but I never > like that name. "flags" sounds more usual. So my concern is more > with the user-visible aspects. I have just send RFA_v3. Note that following the above discussion, I have kept the word 'flag' for the cases where the code and/or documentation are only related to flags, and have no other type of arguments. The wording can be changed whenever other types of options are added and/or when arg parsing is converted to the generalized option parser Thanks for the review comments and suggestions ... Philippe