cederom commented on PR #14460:
URL: https://github.com/apache/nuttx/pull/14460#issuecomment-2459402338
* To move forward and keep things compatible and elegant I proposed Kconfig
selectable type for `time_t` so its not hardcoded and so developers have a
choice.
* We currently discuss on the mailing list whether to split that type
defaults for 32/64-bit platforms and smaller ones, or to have common single
list of types to configure via Kconfig before build for `time_t`, and it turns
out `int64_t` seems best default, while easy switch to `int32_t` or `uint32_t`
is still available for the developer if necessary as required.
* One list of choice should keep this setting crystal clear, in one place,
with conscious manual selection (no hidden inconsistencies, no auto-detection,
no variants, etc), configuration level selectable, no code modification, etc.
* As this selection is crucial it can be printed explicitly on screen
summary as part of configure process.
* @codebje confirmed uding `int64_t` as virtual type variable should have
small impact and is worth solving the 32-bit storage problem whether signed
(Y2038 problem) or unsigned (build errors and on ported GNU software). Biggest
impact will be on Cortex-M0, 16-bit, and 8-bit platforms.
> https://godbolt.org/z/8bKj6an4z
> I don't think, personally, that any of this is reason enough to worry
about it. Using an int64_t for time_t is IMO a perfectly reasonable default for
32-bit and up targets. and possibly for all targets. Offering a kconfig option
to support 32-bit (signed or unsigned) time_t offers an easy work-around should
anyone find that the couple of percent increase in code size and execution time
causes their project to fail - or if anyone is in the unfortunate situation
where they depend on code that's made assumptions about size or signedness.
* @slorquet proposes casting on each time arithmetics as solution to
signed/unsigned problem but leaving defaults as-is.
* @yamt had some objections to configuration selectable `time_t` types but
we are waiting for precise alternative solution proposition. I guess @yamt
along with @slorquet want to keep `uint32_t` as default not the `int64_t` do I
get this right?
* @patacongo what solution sounds best for you? :-)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
