Discussion
Wow, POSIX specifies that the type of the nanoseconds field in struct timespec must be long. Did they have a competition to pick the worst possible choice for that type? It's a value that must be able to hold a (maximum of 30-bit) value from 0 to 999,999,999. So they picked a signed type that is at least 32 bits, but sometimes larger.
@david_chisnall There is so much we could do so much better if we took all the lessons from POSIX, Plan9, Windows, whatever and started building from scratch in the modern day.
I completely understand that in modern world that is extremely unlikely to happen, but building on a questionable foundation as much as we do without even realising the foundation might not be what we'd hoped for is kinda incredible.
With the modern hyper-producitity-seeking institutions, I don't think I'll live to see this change, but it's insane to think how much we already know we could improve on the fundamentals if we just tried to.
@ananas That's more or less what we're doing in CHERIoT RTOS, with some compatibility layers for porting existing stuff. It's much more feasible for embedded, so that's also a place you can demonstrate things that you wish bigger systems did.
@david_chisnall the official rationale is here: https://pubs.opengroup.org/onlinepubs/9799919799/xrat/V4_xsh_chap01.html#tag_22_02_08. It makes sense why they picked a signed type (handling differences). And they also explain why they wanted a 32-bit type.
`long` seems to be the only type guaranteed to be at least 32-bits. But fixed width integer types are also required by POSIX, so it doesn't explain why not those.
Although it looks like this changed in C23, where the type becomes an implementation defined signed integer capable of holding that range (which would allow you to choose th best one for your implementation) https://en.cppreference.com/c/chrono/timespec
I assume that the next POSIX spec update will catch up to the C standard?
Although in practice I don't think it'll matter, time_t is 64-bit already, so with a 32-bit tv_nsec, you'll likely get padding to 64-bit anyway...
@david_chisnall I wonder if they standardised it from implementations that decided to use -1 for "nanoseconds unsupported" or something like that.
It's curious because it's a newer addition. The older timeval provided microseconds and it made both fields a platform-defined typedef, so you can pick whatever makes sense for you.
Install bonfire.cafe
Get the full app experience
