Hi Greg, Rather than reducing the size of time_t and joining the systems with the year 2038 problem, I think that a better solution is to solve the problem permanently. --- Agree with your last part, we should find a better way to ‘ put things right once and for all ’, and not use the unsigned int to *postpone the occurrence of things*
So, Someone thinks time_t will overflow when set int32_t, should think his code should open TIME64 or handle the overflow himself. Gregory Nutt <spudan...@gmail.com> 于2024年11月5日周二 05:24写道： > You are right, there is no requirement by any standard that time_t be > signed. Lots of discussion on Wikipedia: > https://en.wikipedia.org/wiki/Unix_time > > The only motivation for making time_t signed is for compatibility with > GLIBC. For example, some very old Unix systems permit negative time values > for times before the epoch. The penalty for this compatibility with a > non-standard different is a loss of range and the year 2038 problem. > > This is the year 2038 problem: > https://en.wikipedia.org/wiki/Year_2038_problem > > Any product released after this change will fail in the field in 2038. > That could be an issue for a few systems with very long lives. Most OSs > have already fixed the year 2038 problem... but in different ways. See the > Year_2038_Problem for solutions that are fielded now (one fix, ironically, > is to make time_t unsigned). > > Rather than reducing the size of time_t and joining the systems with the > year 2038 problem, I think that a better solution is to solve the problem > permanently. > > > On 11/4/2024 2:50 PM, b...@the-wanderers.org wrote: > > Hi Guiding, > > Both your reference and the Open Group specification documents both only > state that POSIX requires time_t to be an integer type, not a signed > integer. > > The Open Group Base Specifications Issue 8 > <https://pubs.opengroup.org/onlinepubs/9799919799/> > pubs.opengroup.org <https://pubs.opengroup.org/onlinepubs/9799919799/> > [image: favicon.ico] <https://pubs.opengroup.org/onlinepubs/9799919799/> > <https://pubs.opengroup.org/onlinepubs/9799919799/> > > GNU libc additionally mandates a signed integer but notes this is a GNU > extension and not a POSIX requirement. > > The 2024 edition of POSIX has introduced a requirement for time_t to be 64 > bits. As has already been noted this is itself a substantial change. > > Byron > > On 4 Nov 2024, at 11:33 PM, Guiding Li <ligd...@gmail.com> > <ligd...@gmail.com> wrote: > > Hi all: > > We decide change 'time_t' from unsigned type to signed type in PR: > https://github.com/apache/nuttx/pull/14460 > > Because when compile some POSIX library, there always be a warning on > comparison > between time_t and zero. > > For example: > > The following code will generate warnings: > auto now = time(nullptr); > auto last_active_time = GetEventService(self->ctx_)->getActiveTime(); if > (last_active_time + 60 * 1000 / 1000 <= now) { > > src/ams/../controller/controller_timer.h: In lambda function: > src/ams/../controller/controller_timer.h:117:57: warning: comparison of > integer expressions of different signedness: 'long long int' and 'long long > unsigned int' [-Wsign-compare] > 117 | if (last_active_time + 60 * 1000 / 1000 <= now) { > > > And we can find an reference on the official website: > > https://www.gnu.org/software/libc/manual/html_node/Time-Types.html > > On POSIX-conformant systems, time_t is an integer type. > > > The comparation of the merits and shortcomings: > > Advantage: > For the most POSIX applications they assume the time_t as signed and do > compare with 0. > The code will become more compatible after this modification. > > Disadvantage: > None. > > > If there is any question about this, please let me know. > Thanks, > Guiding > >
