Fix: do not add an offset to a nullptr

[TrueBrain]

While at it, prevent a potential cases where an offset would be added to a nullptr (which would be horrible wrong for completely different reasons).

Tnx to milek7 for tracing the root cause.

[LordAro]

Are there any additional changes (asserts, etc) that could be added to prevent this mistake from being made in future?

[TrueBrain]

Went for a slightly different direction; turns out there were more places that are or could potentially feed a nullptr in as object, fully assuming the sld is global. So I no reduced it to an assert(), that should tell us if this is the case. From what I can tell, it never happens currently. If the assert() does hit, something is really wrong, as a non-global variable is read as a global variable; this really would be random behaviour at that point.

[TrueBrain]

And something is wrong: when saving the date, SlGlobList() is called which calls SlObject() with a nullptr, which calls GetVariableAddress() with a nullptr .. and on a non-global, with the address of 0. This on its turn returns a nullptr .. and for some reason that works :P

#4  0x0000555555c45c2b in GetVariableAddress (object=0x0, sld=0x5555568e7340 <_date_desc+128>) at /home/patric/projects/OpenTTD/OpenTTD/src/saveload/saveload.h:877
#5  0x0000555555c489bf in SlObject (object=0x0, sld=0x5555568e7340 <_date_desc+128>) at /home/patric/projects/OpenTTD/OpenTTD/src/saveload/saveload.cpp:1622
#6  0x0000555555c48a01 in SlGlobList (sldg=0x5555568e72c0 <_date_desc>) at /home/patric/projects/OpenTTD/OpenTTD/src/saveload/saveload.cpp:1633
#7  0x0000555555c3b772 in SaveLoad_DATE () at /home/patric/projects/OpenTTD/OpenTTD/src/saveload/misc_sl.cpp:125

This is caused by SLE_CONDNULL, a method to indicate there are bytes there, but we don't care about them anymore (supporting old savegames).

[TrueBrain]

This function is something. This patch changes the behaviour a bit: when a SaveLoad is SLE_VAR_NULL, it will now always return a nullptr. In the old behaviour it could also return object. This shouldn't matter at all, as any read/write to the SaveLoad is a noop in these cases.

[LordAro]

Everything about this bit of the code is horrifying, but I'm happy you've tested it well enough :)