I have to disagree but I also think you may be misreading what I wrote
(and/or that maybe some clarification is needed)
So first - in my opinion, if you apply your logic this strictly, NuttX
is already very much non-compliant. For example - one of the interfaces
POSIX mandates is a sigprocmask system call, correct? My compiled NuttX
binary (with full signal support enabled) does not have that system
call. It is, therefore, non-compliant.
Well, the obvious answer to that is that NuttX is compliant in this
regard, it's just the compiler (linker) figured out that the function is
actually not used from anywhere so it went and removed it.
But this logic applies to the time_t as well. Let's start with the
clarification - my point is not that the application uses 32 bit time_t.
In fact, the word "application" in my message was supposed to mean a
device driven by NuttX - the hardware, the kernel, the userspace
program*
My point is that the application uses whatever time_t is provided by
NuttX - a 64bit wide value to be compliant. Then, in some sufficiently
advanced manner, the compiler recognizes that the application will never
work with values of time_t type which have non-zero upper 32 bits. (Same
for clock_t.) Under these circumstances, the compiler is free to not
store those bits, nor it has to include them in any calculations**. And
- same as with the previous example - the result should still be
considered compliant. (Because, let's be honest here, unless you look to
the assembly output, you will not know it happened.)
Now, since we don't have sufficiently advanced GCC 9000 at our disposal,
such an optimization will not happen automatically. But it is possible
to provide a hint to the compiler manually - and since the final result
is identical to the previous case, it is also compliant.
And I don't think this is a philosophical discussion (replying to the
other post) - providing hints to the compiler is not unheard of. For
example, Linux uses likely/unlikely macros to inform the compiler which
is the more likely result of boolean expression in an if statement. Nor
do I think that anyone would object to compiler reducing data types to a
size that is actually needed, if it was sufficiently advanced to
recognize that it is the case. It actually already does this in trivial
cases.
Also, to make things clear, I am advocating for keeping the option to
reduce time_t to 32 bits by configuration if the user chooses to do
that. If not, use the POSIX-compliant 64bit default.
* and static build. As soon as we talk kernel build, all of this is moot
and you need 64bit time_t. Probably not the case for small chips though
** yes, it also depends on the other operand
