Refactor writing to pointers

[karoliineh]

• Removes dead code that indicates as if we are not writing to known addresses if a pointer contains an unknown element, solves Reconsider not writing to known addresses if a pointer contains an unknown element #1461
• Fixes issue BaseAnalysis: Investigate why join over alternatives for non-definite AD target does not work #1465, and replaces complicated set logic with simplified AD.fold, for that:
  • Asserts that the set of lval-s is not empty when written to
  • Does not remove NullPtr-s from address sets in collect_invalidate and reachable_from_value MayPointTo is not subset of ReachableFrom #1175
  • Fixes a regression test by including stdlib.h for correctly importing strtol
• does not remove UnknownPtr before calling reachable_vars in ReachableFrom MayPointTo is not subset of ReachableFrom #1175

TODO

• Test Fix base must-writing all invalidated variables #1562.

[karoliineh]

Decisions from GobCon on 09.07:

What should happen when we write to a pointer that is either known or NullPtr?

• a) Should we keep the NullPtr and join the known values
• b) Or should we assume that if it is null, the program crashes anyways, and if it continues, the known value can only be the one that was written

• Add b) as default behavior, make it configurable (for now), with option called sem.abort-on-null-deref

[sim642]

We already have the option sem.null-pointer.dereference (for reading) and I think we decided to reuse that for writing. Its name and values might need to be changed though to match both reading and writing.

[michael-schwarz]

This seems to have gotten stuck. Are there plans here?

[sim642]

There was the matter of naming/describing the option but we discussed it and something seems to have been implemented. Not sure about the test failures though.

I think it makes sense to do this though.

[sim642]

[...] Not sure about the test failures though.

The old CI runs seem to be gone, but I now merged master into this and locally at least two malloc_null tests fail.
The path-sensitivity of malloc_null analysis causes a scenario where a path has the malloc-ed pointer as {NULL}. Writing into that pointer, the assert doesn't fail because the points-to set is non-empty, but due to assume_none we end up returning D.bot ().
That bottom is a strange value: it appears live, but has lost all local variables state of base.

I suppose turning a D.bot () result into raise Deadcode could work here.
It does reveal a certain asymmetry with assume_none on NULL pointer reading: the latter doesn't raise Deadcode I think, but just assumes nothing changed.