From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-128369-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 91394 invoked by alias); 30 Dec 2015 21:25:59 -0000
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
Received: (qmail 91385 invoked by uid 89); 30 Dec 2015 21:25:59 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=staring, Hx-languages-length:660, leaders
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:25:58 +0000
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27])	by mx1.redhat.com (Postfix) with ESMTPS id 3B50FC0B7E17;	Wed, 30 Dec 2015 21:25:57 +0000 (UTC)
Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1])	by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tBULPtFe011924;	Wed, 30 Dec 2015 16:25:55 -0500
Message-ID: <56844BE3.9030508@redhat.com>
Date: Wed, 30 Dec 2015 21:25:00 -0000
From: Pedro Alves <palves@redhat.com>
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 <tetra2005@gmail.com>, Yury Gribov <y.gribov@samsung.com>
CC: gdb-patches@sourceware.org, Stan Shebs <stanshebs@google.com>,        Paul Pluzhnikov <ppluzhnikov@google.com>
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> <CAJOtW+7zb01iC7y4unfo6vVPN2z4_eHoD7xn93f-9tRfy7ffag@mail.gmail.com>
In-Reply-To: <CAJOtW+7zb01iC7y4unfo6vVPN2z4_eHoD7xn93f-9tRfy7ffag@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-SW-Source: 2015-12/txt/msg00539.txt.bz2

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.)

Thanks,
Pedro Alves