yamt commented on PR #7975: URL: https://github.com/apache/nuttx/pull/7975#issuecomment-1364926662
> > > No, it's problem when CONFIG_SYSTEM_TIME64 is enabled and time_t is map to uint64_t. So, if you don't have a good reason, it's better to map time_t to int64_t like other OS. For !CONFIG_SYSTEM_TIME64 case, time_t is int32_t, but the other side is uint64_t, so it's safe to prompt int32_t(time_t) to uint64_t without warning. > > > > > > > > * the particular warning in libcxx seems ok to ignore. > > It exists in many places (the above warning is just a demo). I am afraid that not only libcxx but also many other libraries suffer the same issue. it seems like the only failure on the ci. > > > * anyway, our tree does not seem -Wsign-compare clean regardless of this > > But it doesn't have any warning before we define time_t to uint64_t see https://github.com/apache/nuttx/pull/7979 i guess it's far from exhaustive. > > > * IMO consistency within nuttx is a good enough reason > > > > If so, why not change 32bit time_t to int32_t like other OS? > > > > > > because int32_t wraps too soon. > > int32_t can represent time correctly until 2038. The reliable fix is promoted time_t to int64_t like other OS. Typedef time_t to uint32_t mayn't work as your expectation (2106) since many software only test with signed integer(https://en.wikipedia.org/wiki/Year_2038_problem). i suspect broken software is broken anyway, even with 64-bit time_t. > > So, if you want to keep the consistence, I will prefer to map time_t to int32_t insteading map time_t to uint64_t. i feel 2038 is too soon. but it's something the project can decide, i guess. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
