From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24932 invoked by alias); 13 Aug 2012 14:24:30 -0000 Received: (qmail 24880 invoked by uid 22791); 13 Aug 2012 14:24:28 -0000 X-SWARE-Spam-Status: No, hits=-7.4 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,MAY_BE_FORGED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 13 Aug 2012 14:23:57 +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 (8.14.4/8.14.4) with ESMTP id q7DENuNq030074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 13 Aug 2012 10:23:56 -0400 Received: from spoyarek (dhcp223-8.pnq.redhat.com [10.65.223.8] (may be forged)) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q7DENsec008816; Mon, 13 Aug 2012 10:23:55 -0400 Date: Mon, 13 Aug 2012 14:24:00 -0000 From: Siddhesh Poyarekar To: Jan Kratochvil Cc: gdb-patches@sourceware.org Subject: Re: bitpos expansion patches summary Message-ID: <20120813195324.76d59a8c@spoyarek> In-Reply-To: <20120813141236.GA7325@host2.jankratochvil.net> References: <20120805005350.150e5b74@spoyarek> <20120812175730.GA5968@host2.jankratochvil.net> <20120813082124.2b80ffdf@spoyarek> <20120813134915.GA5960@host2.jankratochvil.net> <20120813193313.666715e1@spoyarek> <20120813141236.GA7325@host2.jankratochvil.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: 2012-08/txt/msg00362.txt.bz2 On Mon, 13 Aug 2012 16:12:36 +0200, Jan wrote: > I am reluctant to check in the LENGTH expansion before getting all > the needed pre-requisite bits fixed. One cannot properly > regression-splint-check it afterwards anymore as HEAD is a moving > target so it may start to be seriously difficult to be tracking the > changes happening between LENGTH expansion and before all the other > bits get it. The splint results will have changing line numbers etc. > > Maybe it is possible to handle it somehow but I would find easier to > check the LENGTH expansion only as the last piece. > OK, I'll make a separate patch of it then, like I am doing for the size_t bits. Regards, Siddhesh