Hi, On Sat, 13 Oct 2012, Lawrence Crowl wrote:
> > > I have no problem in always returning a status change, if you are OK > > > with that. > > > > I am ok with that. > > There is some rationale for being concerned about performance, as the > checking routines need to read memory locations that they otherwise > would only write. If the destination is one of the sources there will be a read anyway. If it's not there will be a small penalty if it isn't in cache yet, though it will be soon because of the write. > I haven't done any performance measures, but I take as evidence that > someone thought there was enough of a performance difference to make it > worth the extra work of writing a second set of routines. Nope. It was valgrind that caused the introduction of the sbitmap _cg functions. If the destination was no input and wasn't initialized the computation of the changed flag (and it's comparison with zero) depended on uninitialized memory, sometimes flagged by valgrind also when the return value wasn't used. I think it should have been handled by valgrind suppressions, not by introducing another interface. Given this, and that the other bitmap interfaces mostly return a changed flag, we should opt for the simpler API, always returning it. That includes the few remaining bitmap.h functions that aren't already doing so. Ciao, Michael.