nodetool::peerlist_entry relies on time_t being a specific size. about monero HOT 6 CLOSED

Unfortunately I don't see a short-term solution to this without resorting to dirty tricks.

To me it looks like peerlist_entry is going out over the wire, so unless I'm mistaken we're kind of stuck using time_t until we have a strategy for updating the wire protocol.

I also looked into getting MinGW to use a 64-bit time_t as a temporary solution. It does on 64-bit, and it seems as if they're working on it for 32-bit, but so far I haven't found a compiler-level workaround.

So as of right now my plan is to try to manually serialize/deserialize back and forth from the 64-bit value to a 32-bit one on platforms where time_t is 32-bit. This sounds dangerous to me, but hopefully it won't end up being any more dangerous than using time_t as part of the wire protocol in the first place.

I'm definitely open to alternative ideas.

from monero.

What are the chances of a time_t value exceeding 32-bits? That's the only time I can see serialising/deserialising between the two as being an issue.

from monero.

I don't think it will be an issue until 2038.

from monero.

If there are any 32-bit users in 2038 I'll personally hunt them down and give them a 64-bit computer. Let's go along with that solution and see how it goes:)

from monero.

Hahaha -- OK, sounds good to me :)

from monero.

The commit above seems to work on my system.

I thought about it some more, and, as I outlined in the commit message, by serializing time_t directly, the existing code was implicitly assuming that time_t is int64_t since that's what the major compilers use. So to me the cleanest solution seemed to be serializing int64_t directly and casting as appropriate.

Assuming this works for everyone, I'll merge it into the mingw/daemonize branch.

from monero.