From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29864 invoked by alias); 22 Jun 2009 13:06:58 -0000 Received: (qmail 29808 invoked by uid 22791); 22 Jun 2009 13:06:56 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-ew0-f225.google.com (HELO mail-ew0-f225.google.com) (209.85.219.225) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 22 Jun 2009 13:06:44 +0000 Received: by ewy25 with SMTP id 25so404511ewy.8 for ; Mon, 22 Jun 2009 06:06:41 -0700 (PDT) Received: by 10.210.11.13 with SMTP id 13mr7294404ebk.96.1245676001746; Mon, 22 Jun 2009 06:06:41 -0700 (PDT) Received: from ?192.168.2.99? (cpc2-cmbg8-0-0-cust61.cmbg.cable.ntl.com [82.6.108.62]) by mx.google.com with ESMTPS id 7sm284381eyg.22.2009.06.22.06.06.40 (version=SSLv3 cipher=RC4-MD5); Mon, 22 Jun 2009 06:06:41 -0700 (PDT) Message-ID: <4A3F84C7.2000004@gmail.com> Date: Mon, 22 Jun 2009 13:06:00 -0000 From: Dave Korn User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Richard Guenther CC: Dave Korn , Daniel Berlin , Jeff Law , GCC Subject: Re: (known?) Issue with bitmap iterators References: <4A3CF81C.7050406@redhat.com> <4aca3dc20906211944hb27a3day21bc22c8a9f58aee@mail.gmail.com> <4A3F6ED1.6020106@gmail.com> <84fc9c000906220437t2d6fcb8fx6a59a45b7ed49abd@mail.gmail.com> In-Reply-To: <84fc9c000906220437t2d6fcb8fx6a59a45b7ed49abd@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-06/txt/msg00506.txt.bz2 Richard Guenther wrote: > On Mon, Jun 22, 2009 at 1:45 PM, Dave > Korn wrote: >> Daniel Berlin wrote: >> >>> Also, what do you expect the semantics to be? >> Since we don't expect an iterator to return the same bit twice when >> iterating in any case, the ideal would be that it shouldn't matter what >> happens to bits that the iterator has already passed. >> >>> In particular, are new bits past the current index iterated over, or >>> do you expect to iterate over the bitmap as it existed at the time you >>> started iteration? >> That would be an ecumenical matter! Err, I mean ... maybe the best solution >> (particularly in terms of preventing future bugs) would be for opening an >> iterator to put the bitmap into a read-only mode that causes bitmap_clear_bit >> or bitmap_set_bit to fail, and that automatically clears when the iterator >> runs off the end? > > Heh, that sounds useful. Keep bitmaps forced readonly during > iterating over them but be able to actually verify it. > > Might need some new exit-from-iterating magic though. I took a look. I don't think it would be hideously hacky to do something like ... #define EXECUTE_IF_SET_IN_BITMAP(BITMAP, MIN, BITNUM, ITER) \ for ((BITMAP)->ro_flag = true, \ bmp_iter_set_init (&(ITER), (BITMAP), (MIN), &(BITNUM)); \ (BITMAP)->ro_flag = bmp_iter_set (&(ITER), &(BITNUM)); \ bmp_iter_next (&(ITER), &(BITNUM))) cheers, DaveK