I've been trying to connect a server and client both running on my laptop, one in a physical Linux installation, and one in a Windows Virtualbox VM. Whichever way round I do it, I can get the client to recognise the server. However, in both cases the client is reporting an incorrect revision for the server.
The Revision is 43ea53503
A Windows client reports the Linux server revision as 3ea53503
A Linux client reports the Windows server revision as 7fffffff (There may have been a different number of fs)
In both cases I am starting the server by adding -server at the command line. In all cases the client and server correctly identify their own revision in the titlebar.
I've really not sure what is going on, or how to go about investigating this, given how little I know of the flow of the networking code.
That is very odd. I am afraid that I also know very little about the networking code, as I did not write it and the only modification that I have made was to change the SVN revision number to the GIT commit number; I have now forgotten most about what I did with that, except that I had to ask others how to do it.
Have you tried reverting your earlier change to this part of the code to see whether this helps?
One thing that one might want to check is whether there is any variable anywhere used to store the revision number that does not have enough bits allocated. The number 43ea53503 in hexadecimal is equal to 18,230,883,587 in decimal, whereas the maximum value of an unsigned 32-bit integer is 2,147,483,647, suggesting that we need a 64-bit depth for storing this number. If there is any code anywhere that stores this in a 32-bit variable, this might be responsible for the issue.
https://forum.simutrans.com/index.php/topic,15523.msg158071.html#msg158071 was ignored.
And the version must fit a sint32. i.e 9 hex chars too much...
Quote from: TurfIt on January 03, 2019, 01:18:22 AM
https://forum.simutrans.com/index.php/topic,15523.msg158071.html#msg158071 was ignored.
And the version must fit a sint32. i.e 9 hex chars too much...
Thank you for that - looking at that thread from last year, it appears that I missed that specific point amidst a great number of other things that I was trying to understand at the time. Perhaps the number of characters should be reduced to 7 to fit into a 32-bit integer?
Ah. In which case we should force that to be 7 characters, and then I think it should work. The differing behaviour will be because signed int overflow is undefined.
I've pushed the fix (hopefully) for this to my Github.
As it happens, reverting wouldn't have made a difference to me because I was already getting 9-character revision strings by default.
Splendid, thank you for that. Now incorporated.
Still won't work until you nuke atol().
Is atol() still present in places where it might need to parse the relevant hexadecimal number? Looking at the other thread, I had noted that I had replaced the relevant instances with strtol() - had I missed one?
Can I take it that A. Carlotti's patch fixed this, incidentally?