[squid-dev] [RFC] nullptr conversion (again)

[Amos Jeffries]

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