From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28422 invoked by alias); 28 Oct 2013 17:53:44 -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 28410 invoked by uid 89); 28 Oct 2013 17:53:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.6 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham 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 ESMTP; Mon, 28 Oct 2013 17:53:43 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r9SHrfBu005784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 28 Oct 2013 13:53:42 -0400 Received: from barimba (ovpn-113-94.phx2.redhat.com [10.3.113.94]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r9SHreVO020952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 28 Oct 2013 13:53:41 -0400 From: Tom Tromey To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [PATCH v4 3/9] add target method delegation References: <1382464769-2465-1-git-send-email-tromey@redhat.com> <1382464769-2465-4-git-send-email-tromey@redhat.com> <526E8B54.8040104@redhat.com> <87eh75cmig.fsf@fleche.redhat.com> Date: Mon, 28 Oct 2013 17:53:00 -0000 In-Reply-To: <87eh75cmig.fsf@fleche.redhat.com> (Tom Tromey's message of "Mon, 28 Oct 2013 11:51:03 -0600") Message-ID: <87a9htcme3.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2013-10/txt/msg00871.txt.bz2 >>>>> "Tom" == Tom Tromey writes: Tom> It seems to me that the best approach is to make a target_delegate_* Tom> function assert only when there is no de_fault for the corresponding Tom> method. I mean, when there *is* a de_fault. The idea is that if there is a de_fault, then the slot cannot be NULL. So, delegation must never fail. On the other hand, if there is no de_fault, then the slot can be NULL, and what exactly to do depends on the method in question. But looking more closely at the code on the branch, there is an assertion in those methods returning something other than void. I'll think about it some more. Tom