From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117238 invoked by alias); 8 Aug 2015 00:04:12 -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 117227 invoked by uid 89); 8 Aug 2015 00:04:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Sat, 08 Aug 2015 00:04:11 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 0776F859F8; Sat, 8 Aug 2015 00:04:09 +0000 (UTC) Received: from valrhona.uglyboxes.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t78048pg017361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Aug 2015 20:04:08 -0400 Subject: Re: [PATCH v3 00/19] New completer API To: Andrew Burgess References: <20150806191404.32159.50755.stgit@valrhona.uglyboxes.com> <20150807225655.GA2986@embecosm.com> Cc: gdb-patches@sourceware.org From: Keith Seitz X-Enigmail-Draft-Status: N1110 Message-ID: <55C54778.2030004@redhat.com> Date: Sat, 08 Aug 2015 00:04:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150807225655.GA2986@embecosm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2015-08/txt/msg00208.txt.bz2 On 08/07/2015 03:56 PM, Andrew Burgess wrote: > I think that the above text is out of date w.r.t. the example below, > in the above you talk about maybe_add_completion, but in the example > below you use the add_completion wrapper. A small detail and > unimportant detail; unless I'm missing something, in which case > ... I'm confused! > Yup, you're right. s/maybe_add_completion/add_completion/g. > I wonder, looking at add_completion, do users _care_ about the reason? Users? No. Developers? Yes. add_completion either returns ..._OK, meaning that more completions may be added. ..._MAX_REACHED meaning that no more completions should be added (but will just waste cycles). The return value does not indicate whether the addition was successful. Just whether more may be added. > Of all the possible return codes from add_completion, I think we can > classify them as either "stop trying to add completions please", or > "feel free to add more completions". Yup. > Could the add_completion interface be simplified to simply return a > bool, true if more completions can be added, false if not? I don't like boolean return values in this case. Forget knowing what happens under the covers (or now that you've read the proposed API). Just by reading "bool add_completion (struct completer_data *, const char *);" can you tell what the boolean return value means? My first reading of that would be "the addition was successfully completed," but that's not what it means in this specific case, because the return value indicates something entirely different. But now I wonder if I am missing something. Is defining an enum going to choke some compiler? Does it violate, or is it ambiguous in, the language? Or is it simply a matter of style? Keith