From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29699 invoked by alias); 14 Nov 2008 19:43:01 -0000 Received: (qmail 29669 invoked by uid 22791); 14 Nov 2008 19:43:00 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-1.vmware.com (HELO smtp-outbound-1.vmware.com) (65.115.85.69) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 14 Nov 2008 19:42:24 +0000 Received: from mailhost5.vmware.com (mailhost5.vmware.com [10.16.68.131]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id DD47516002; Fri, 14 Nov 2008 11:42:22 -0800 (PST) Received: from [10.20.92.59] (promb-2s-dhcp59.eng.vmware.com [10.20.92.59]) by mailhost5.vmware.com (Postfix) with ESMTP id D3DC2DC0E2; Fri, 14 Nov 2008 11:42:22 -0800 (PST) Message-ID: <491DD486.1070407@vmware.com> Date: Sat, 15 Nov 2008 16:10:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Vladimir Prus CC: "gdb-patches@sources.redhat.com" Subject: Re: [RFC] Implement -list-thread-groups. References: <200811122333.29218.vladimir@codesourcery.com> <200811142100.56244.vladimir@codesourcery.com> <491DC976.4050506@vmware.com> <200811142218.17090.vladimir@codesourcery.com> In-Reply-To: <200811142218.17090.vladimir@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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-11/txt/msg00371.txt.bz2 Vladimir Prus wrote: > On Friday 14 November 2008 21:54:46 Michael Snyder wrote: > >>>> I'm puzzled by this assert. >>>> You don't think we'll ever want to specify both the pid and the thread? >>> I think that makes no sense. If a thread is specified, then there's no >>> possible use of 'pid'. Threads are globally numbered. >> Even if it makes no sense in the sense that >> it's not required, that doesn't necessarily make it >> an error. Suppose somebody specifies both the pid and >> the thread? What's the harm? If they're inconsistent >> (this pid does not contain this thread), THEN we'll >> return an error. > > I think it's better to make functions have as tight preconditions as possible. > In this case, passing both thread and pid does not serve any possible purpose, > so it's likely that caller is doing this by mistake. It's best to assert > immediately, rather than spending time and code space verifying if those > parameters are consistent. I respect your opinion, but MI is not the only caller of this function. > Checking if a thread belongs to a process is not > the part of this this function purpose. It's input validation. What you're doing is also input validation, it's just imposing a more stringent requirement. I feel that an assert is excessively stringent in this context. An assert implies an internal gdb error. These potentially conflicting inputs could come about as a result of (foreseeable) user input, rather than internal error. Admittedly not any user input that could be given now, but the CLI (or other potential clients) could change. I feel that if it's possible for these inputs to violate the assert without actually reflecting an internally inconsistant state, then the assert is too strong.