Re: (known?) Issue with bitmap iterators

[Dave Korn <dave dot korn dot cygwin at googlemail dot com>]

Richard Guenther wrote:
> On Mon, Jun 22, 2009 at 1:45 PM, Dave
> Korn<dave.korn.cygwin@googlemail.com> 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