negative ticks

[Mariculous]

Ticks usually seem to be stored as sint64. I was wondering why. At a first look negative timespans nor negative points in time really make sense.
The only thing where times before map creation make sense are introduction dates of vehicles and so on but these are not stored in ticks at all.
I decided to set a watch for ticks<0 in some places of the code, and I found at leas one one!

The following might be related to https://forum.simutrans.com/index.php/topic,18873.0.html.

In simhalt.cc, line 2633, there will be a negative tick value passed, when "this_arrival_time" is zero.
This seems quite strange to me and might cause the above linked bug.
It is quite easy to track this down to the hashtable_tpl::get call.
In case of misses, i.e. passing a key that does not exist in the table

Code Select Expand


static value_t nix;
//code attempting to find the element
return nix;

In case of misses, i.e. passing a key that does not exist in the table, hashtable_tpl::get will simply return "nix", Which in this case is 0.
I am however not even sure if the declaration of nix is guaranteed to be NULL initialised.

Handling a get call to an element that does not exist in the table, however is difficult.
In this case usually an exception is thrown or a get_or_default(key, default) method is offered alternatively.

Silently ignoring the miss and returning "nothing" will lead to issues somewhere far far away at some other corners of the code.

[jamespetts]

There are several layers to this:
(1) how a hashtable handles a request to return a value that does not exist;
(2) how the code in simhalt.cc handles the situation when a hashtable does the above; and
(3) why the convoy in question might not be in the hashtable in the first place.

No. 1 is not something that I can sensibly deal with, as this is identical with Standard and I have not looked at the low level parts of the collection class code.

No. 2 is potentially more straightforward: I have pushed a fix that should deal with this by checking for a zero value and using the current time instead.

As to no. 3, it is not immediately clear to me (without a lengthy investigation at least) why this should occur - but I have added a debug output error message in the handling stated at no. 2, so this should be slightly easier to track down in the future.