Even if "strict POSIX" wasn't intended to be a top priority, it deserves to be. The reason is simple: it's probably the most testable and measurable principle in INVIOLABLES, based on rigidly established rules. The other items in INVIOLABLES are more fluid and open to interpretations.
I'm all for the ability to tune the OS and disable unnecessary features. This is the best part of NuttX. The main problem I see with time_t is that it's a fundamental primitive in the system. While excluding OS features from compilation that are unused or unavailable in hardware seems fine (if they are disable they are not used anyway), incompatibility at the API definition level seems more problematic. Unless we treat the 32 bit time_t option as "disabling the upper 64-bit half that is not used anyway" optimisation. But here we're getting more into philosophy, not technical discussions :) pon., 4 maj 2026 o 19:45 Gregory Nutt <[email protected]> napisał(a): > > Example: a toaster shouldn't need a big powerful MCU. 8-bit MCU should be > plenty. And you're not going to toast a piece of bread for more than 50 > days. Maybe 50 seconds max. And if you're mass producing toasters, saving a > few cents per MCU by choosing one with less flash and RAM will save a lot > of money. So in this case the developer may decide that time_t should be > reduced because it makes sense. > > Remember that the range of time_t has to support the epoch as the minimum > (zero) value. Now is the running time plus the epoch (CLOCK_REALTIME). >
