From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 99709 invoked by alias); 30 Dec 2015 21:35:28 -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 99700 invoked by uid 89); 30 Dec 2015 21:35:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=staring, leader, Lets, Let's 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; Wed, 30 Dec 2015 21:35:26 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 72B2DC0B7E02; Wed, 30 Dec 2015 21:35:25 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tBULZNxP015488; Wed, 30 Dec 2015 16:35:24 -0500 Message-ID: <56844E1B.20507@redhat.com> Date: Wed, 30 Dec 2015 21:35:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Yuri Gribov , Yury Gribov CC: gdb-patches@sourceware.org, Stan Shebs , Paul Pluzhnikov Subject: Re: [PATCH][PING][PR gdb/19361] Fix invalid comparison functions References: <566FFEE2.4010300@samsung.com> <56823702.6020804@samsung.com> <5682C264.3030109@redhat.com> <5682CC66.70608@samsung.com> <56844BE3.9030508@redhat.com> In-Reply-To: <56844BE3.9030508@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-12/txt/msg00540.txt.bz2 On 12/30/2015 09:25 PM, Pedro Alves wrote: > On 12/30/2015 08:18 PM, Yuri Gribov wrote: > >> Sorry, I should have been more wordy about the actual problem. With >> current approach i.e. >> >> if (pid1 == pgid1) >> return -1; >> else if (pid2 == pgid2) >> return 1; >> >> comparison of two group leaders is not going to be symmetric: >> >> cmp(lead_1, lead_2) == cmp(lead_2, lead_1) == -1 > > Aaaaaaah, d'oh! Thanks, it's obvious now, yes, we fail to consider > the case of both elements being leaders. I couldn't see that > even after staring at the code for a while. That hunk is OK as > is then. (Please clarify this in the commit log.) Wait, no we don't... If both are leaders when you get there, then they must have different pgid's, and that case is handled before: /* Sort by PGID. */ if (pgid1 < pgid2) return -1; else if (pgid1 > pgid2) return 1; else But let's assume not. Let's assume we see two leaders when you get to the code in question. That means they have pgid1==pgid2. Since by definition being leader means pgid==pid, it must be that pid1 == pid2 as well. That is, this is really about comparing equivalent elements. Which brings us back again to: /* Easier to check for equivalent element first. */ if (pid1 == pid2) return 0; Or am I confused again? Thanks, Pedro Alves