On 10/15/12, Michael Matz <m...@suse.de> wrote: > 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 agree that if the destination is a source, there is little cause for concern. However, there are routines in which the definition is write only. > > 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. Agreed. > 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. Does anyone have objections to this plan? -- Lawrence Crowl
