On 13/04/2017 4:10 a.m., Alex Rousskov wrote: > On 04/12/2017 09:53 AM, Amos Jeffries wrote: >> I have been thinking of this again and think I have come up with a way >> to make some better progress. >> >> The idea is to split the NULL -> nullptr changes into two groups: >> >> 1) those lines where sed s/nullptr/NULL/g can be used to reverse the >> change completely in backports to 3.x >> >> 2) everything else. Some refactor is needed so that can stay with the >> current as-touched policy. > > ... > >> Forward-porting of code will still have some merge related pain > > Other sources of pain will include "v5 to v4" and "v5 to any v5-based > branch" porting AFAICT.
Any collisions there will be the lines I bring up in audit as needing changes to remove the NULL anyway. So the choice is one-off pain now or delays plus extra pain and maybe extra re-testing in audit. So, "bzr merge --take-this -c... " handles the merge from the main branch painlessly and the leftover lines are the above set. So a few minutes checking the "bzr diff -rsubmit: " patch after the merge is time spent reducing the audit pain. > > Is it really difficult to write a script that will rename most NULLs > that are safe to rename without breaking anything? Perhaps I am > forgetting some context here, but what is the primary reason why making > such a script is so difficult? > IMO it is pointlessly simple or too complex to do. The 'pointlessly simple' part is that; a) branches can use "bzr merge --take-this -cNN ..." and the hunks/lines which are ignored are the ones which need manual attention or they will impact the audit anyway as mentioend above. b) patches can (usually) use sed NULL/nullptr or the reverse. NP: This is actually *less* painful when dealing with fully converted vs non-converted code. So our partial drip-feeding of changes to mainline is actively preventing this simple handling of some patches. The 'too complex' part is where major refactoring is needed with change spread over multiple files. Such as the C++11 initialization sequence cleanups. It is a bit mind-numbingly for me/us manually but a script to do that right every time would be effectively AI. My main aim in this proposal is to try and reduce the signal-to-noise ratio as it were when we see a NULL still in the code. If I can get this work agreed and applied then the remaining NULL's become another useful tag we or beginners can grep for (like TODO or XXX) that finds small-ish things to do. While the compilers meanwhile get their tiny smidge of extra optimization. Amos _______________________________________________ squid-dev mailing list [email protected] http://lists.squid-cache.org/listinfo/squid-dev
