On Mon, Oct 29, 2012 at 2:46 PM, Lawrence Crowl <cr...@googlers.com> wrote:
> Okay, but I point out that there is an awful lot of #if 0 code > out there. I would rather have done such removal in a followup > patch. Sure. But the point is not to add more. We should mechanically strip all the #if 0 code from the tree, btw. No point keeping all that garbage around. > The sbitmap popcount function is only used in ebitmap, which is > itself not used. If we do anything, removing them might be the > thing to do. Yes, please. > The bitmap.h iterators set and the sbitmap.h iterator set intersect > in one element. I would rather treat the iterator conversion as > a separate patch. OK, but this would be for 4.8, right? > Richard said in an earlier mail, "I'd rather not mix this with > any kind of further C++-ification (that is introduction of member > functions or operator overloads)." So, exactly what are you > all after? I'm after full unification. The patch seemed to stop short of doing that. If you are going to do follow-up patches, that would be fine. But stage 1 is closing, and I'd like to have this done for 4.8. I want to minimize partial transitions. We have too many of those already. > Yes, I meant that. There are no functional changes here. Why is > contrib/config-list.mk not sufficient? Just to make sure. Testing on ppc should be fast, for example. Diego.