There are a couple of topics mixed into this thread: 1. clang sometimes gives "false positives". Here the code is usually so complex that I can understand that clang and programmers have trouble following the code. The best way would be to refactor the code to be simpler, in one case I split a long and complicated fn instead of using an assert.
I'm not saying that clang can't give silly false positives, but when it does give false positives, it's oftentimes in too-long functions. So far I have yet to see clang give silly warnings on highly readable code. 2. the gerrit review process and build system is new, so I've been using simple warning fixes to take it for a spin. 3. w.r.t. the review process, I was thinking if we should have a rule like: a patch can be submitted if a week has gone without feedback and it looks good, or a second reviewer approves it. -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 http://www.zylin.com/ _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
