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]

Regarding something I noticed in #1777 (comment): this now makes writing to NULL more explicit, but somehow there's still no warning.
I'm now wondering if we're actually missing a warning here or we actually emit one from somewhere else already. Should probably figure this out while we're at it.