Fix issue with time_t being a int64_t on some platforms

[skilau]

This PR fixes an issue we have on our platform, where time_t is a int64_t instead of the assumed uint32_t.

We ran into a problem where when stopping the daemon, and restarting it would fail to properly load the neighbor cache, and would cause the cached nodes to be rejected until their 30 minute timeout expired on their side, and eventually gave up, and reconnected.

This issue was quite puzzling at first, but adding debugging to the loading of the neighbor cache files showed that the cached neighbors were all being loaded, and then promptly being rejected as being too old, and flushed/deleted away.

When digging into a neighbor cache file, we discovered the issue, here is an example of the issue before the fix:

ipv6[0] = fd00:5425:5c08:3e2:435c:8d05:ac0d:5fa8
lifetime[0] = 2220
# Fri Oct 10 04:01:16 2025 UTC
expiration[0] = 3118
ipv6[1] = fe80::8a0f:62ff:fe10:aa93
lifetime[1] = 600
# Fri Oct 10 03:34:07 2025 UTC
expiration[1] = 3118

If we look at the values for the expiration[], they are far too small to be realistic, even though the comment above them shows the proper timestamp in text format, so we knew that the time_t value was correct and not corrupt at that time.

Looking at the code that generates that line, we found the problem.
It was doing a printf() with "%lu", instead of the "%llu" that it needed to be, for platforms that have a time_t that is set to a uint64_t. (Or int64_t, etc)

Changing it to "%llu" (or "%ju) gets us the correct value, which would be the standard unix timestamp that we all expect:

ipv6[0] = fd00:5425:5c08:3e2:435c:8d05:ac0d:5fa8
lifetime[0] = 2220
# Fri Oct 10 05:49:00 2025 UTC
expiration[0] = 1760075340
ipv6[1] = fe80::8a0f:62ff:fe10:aa93
lifetime[1] = 2220
# Fri Oct 10 05:49:00 2025 UTC
expiration[1] = 1760075340

This fixes our existing problem.

We did notice that another "expiration_s" value was called out as a uint32_t, in one of the headers, so I have made the change to time_t there, and included the change in this PR.

This seems to also work fine, and we haven't noticed any problems with these changes so far.

The tools platform we are on, which is what is providing the 64bit time_t change, is:

# ldd
musl libc (arm)
Version 1.2.5
Dynamic Program Loader
Usage: ldd [options] [--] pathname

The typedef is here:
https://git.musl-libc.org/cgit/musl/tree/include/alltypes.h.in#n12

[MathisMARION]

Hello, and thank you for the detailed investigation and bug fix. We have experienced this kind of issue in the past with the width of time_t. This is a combination of the native integer sizes, and the type definition for time_t. We have tested:

• time_t as long and sizeof(long) == 4.
• time_t as long and sizeof(long) == 8.

It seems that your platform has time_t as a long long with sizeof(long) == 4 and sizeof(long long) == 8.

I believe you should have gotten a compilation warning of this kind, is it not the case?

warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘long long int’ [-Wformat=]

As for the other edit inside struct ws_neigh, the field appears to be unused, we will remove it.

[skilau]

Yes, we actually went with this for now, in our code:

fprintf(nvm->file, "expiration[%d] = %" PRId64 "\n", i, ts);

as getting the printf() right when it could be a uint32_t, uint64_t or int64_t is kind of painful, I am not sure what the best printf format would be to be compatible with all the platforms wsbrd supports.

[MathisMARION]

You should have received an edited version of your patch by email. We tend to do our internal review by email, but don't worry about it unless you have extra comments to make. I actually did not mean to add you as a cc but here we are 😅 Your patch will be applied to our internal repo and hopefully released as part of v2.7 (supposedly this week).