Re: Change time_t to signed type

2024-11-08 Thread Gregory Nutt

On 11/8/2024 1:41 AM, Takashi Yamamoto wrote:

have you decided that targets w/o 64-bit integers are not good enough
reason to diverge from what the latest posix says about time_t?
are we effectively dropping those targets?


Anything that has a GCC port should have int64_t.  For other cases, it 
will depend on the toolchain.  I think that only z8, z80, z180,  and 
zNEO would be a problem.


Of these, I consider only z180 to be of any value because it is often 
used in contemporary FPGAs.  The others suffer from numerous issues much 
larger than time_t:


 * z80 - I think NuttX outgrew the 64Kb address space years ago. There
   is no viable toolchain for z80 (or z180).  SDCC has some of the same
   broken behavior as ZDS-II.*
 * z8 and zNEO - These depend the ZDS-II toolchain which will never be
   supported again.  It will not support many other POSIX definitions. 
   We burned that bridge years ago in order to keep NuttX consistent
   with POSIX.  There was never a verified port of z8.

   * Specifically, they cannot pass structure or union types by value. 
   They cannot return values if these tyoes either.  This breaks
   numerous POSIX interfaces.  There once was an option to change the
   POSIX interfaces just for these toolchains, it worked but was
   removed to avoid conditional POSIX support.  See commit
   67ec3d7926d871c515fb1a55a11da8630fe53649

There was one person (other than me) that had hopes for zNEO. But the 
silicon was too buggy and ZiLOG basically stopped maintaining zNEO after 
it was sold.


https://zilog.com/ is now owned by Littlefuse.  Perhaps they will be 
better custodians than their previous foster family.


I can just do nothing with these architectures.  These have been broken 
for years and the change to time_t does not effect their broken-ness.  
Or, since they have not value, they could just be removed.  It would be 
nice to keep z180, if possible.


Re: Change time_t to signed type

2024-11-07 Thread Takashi Yamamoto
On Fri, Nov 8, 2024 at 3:42 AM Gregory Nutt  wrote:
>
>
> On 11/7/2024 12:34 PM, Tomek CEDRO wrote:
> > Still it will be possible to set _by_hand_ other values (i.e. int32_t
> > or uint32_t) via kconfig when necessary for older / smaller platforms.
>
> But not POSIX 2024 compliant.  We have forbid non-compliant options in
> the past.  The option would basic say "Select to make NuttX
> non-compliant with POSIX."  We don't usually allow that kind of option;
> many useful Kconfig options have been removed just that reason.  Since
> the size of time_t is 64-bits in all cases, I think we have to comply.

have you decided that targets w/o 64-bit integers are not good enough
reason to diverge from what the latest posix says about time_t?
are we effectively dropping those targets?


Re: Change time_t to signed type

2024-11-07 Thread Tomek CEDRO
On Thu, Nov 7, 2024 at 7:42 PM Gregory Nutt  wrote:
> On 11/7/2024 12:34 PM, Tomek CEDRO wrote:
> > Still it will be possible to set _by_hand_ other values (i.e. int32_t
> > or uint32_t) via kconfig when necessary for older / smaller platforms.
>
> But not POSIX 2024 compliant.  We have forbid non-compliant options in
> the past.  The option would basic say "Select to make NuttX
> non-compliant with POSIX."  We don't usually allow that kind of option;
> many useful Kconfig options have been removed just that reason.  Since
> the size of time_t is 64-bits in all cases, I think we have to comply.

Ah, okay, POSIX.1-2024 / IEEE Std 1003.1-2024 / The Open Group
Standard Base Specifications, Issue 8 [1] says: "time_t shall be an
integer type with a width (see  ) of at least 64 bits" [2].

So in the end `int64_t time_t` only? :-)

[1] https://pubs.opengroup.org/onlinepubs/9799919799/
[2] https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/sys_types.h.html

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info


Re: Change time_t to signed type

2024-11-07 Thread Tomek CEDRO
On Thu, Nov 7, 2024 at 7:01 PM Gregory Nutt  wrote:
> On 11/7/2024 10:59 AM, Tomek CEDRO wrote:
> > Does adding kconfig's configurable time_t with uint32_t default
> > (as-is) with option to change int32_t and int64_t sounds good? Should
> > we use manual selection only or auto-detection (i.e. int64_t on 64-bit
> > archs)? :-)
>
>  /Initial Response /
>
> Not really.  The POSIX specification for time_t is still under work.
> Just changing the type to int64_t  is one likely result amongst others.
> I would not invest the effort in the timing calculations for an
> arbitrary non-standard solution.  I would wait for the specification to
> be released and not waste effort guessing what the standard will be.
>
> "In a future version of this volume of POSIX.1-2017, *time_t* is
> likely to be required to be capable of representing times far in the
> future. Whether this will be mandated as a 64-bit type or a
> requirement that a specific date in the future be representable (for
> example, 1 AD) is not yet determined. Systems purchased after
> the approval of this volume of POSIX.1-2017 should be evaluated to
> determine whether their lifetime will extend past 2038."
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/time.html
>
> If you are a gambling man and don't mind the risk of re-working time_t
> related logic, then I would bet on the type being int64_t as you are
> advocating.  What will be the units of time?  Still 1 sec?  Probably
> not.  Perhaps time_t will become a structure?  We don't really know.
> int64_t is not a bad bet but not substantiated by specification yet either.
>
> > This provides backward compatibility, easy configuration versatility /
> > fine tuning, and we may change the default when new POSIX standard is
> > ratified? :-)
>
> Which might be a big job and might make all of that non-standard,
> unspecified implementation throw-away code.If someone wants to go
> through that effort and verify/fix all of the timing calculation
> functions as needed to support int54_t time_t, I would not oppose that.
>
>  /LATER /
>
> */Never mind/*. POSIX 2024 has just been released and time_t is now
> required to be 64-bits. Lots and lots of other changes as well.
>
>   * https://sortix.org/blog/posix-2024/
>
> The 2038 32-bit |time_t| apocalypse has been canceled to contain
> SCP-8601 .
>
>   * 
> https://www.reddit.com/r/C_Programming/comments/1e2ac63/new_features_for_c_in_posix_2024/?rdt=50686
>
> |time_t| is now required to be 64-bit. Farewell year 2038 problem.
>
> I have seen on these POSIX summaries and would really like to see the
> language of the actual spec. At any rate, will a solid basis in
> specifications. I now agree with you. time_t must 64 bits on all
> platforms and with all tools.

Yes Byron referenced POSIX 2024 a bit earlier this is exactly why I
proposed to set int64_t time_t as default already :-P :-P

Still it will be possible to set _by_hand_ other values (i.e. int32_t
or uint32_t) via kconfig when necessary for older / smaller platforms.
I like the idea of auto-detection but I am afraid this will lead to
inconsistencies and confusion so nothing is done behind the back and
if developer wants to change time_t type it should be manual conscious
choice :-)

I must underline here how much I really love NuttX - no rush, no
enforced changes, in depth analysis and constructive approach by the
small but mature developers community - what a wonderful environment
to learn and grow, thank you :-)

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info


Re: Change time_t to signed type

2024-11-07 Thread Gregory Nutt



On 11/7/2024 12:34 PM, Tomek CEDRO wrote:

Still it will be possible to set _by_hand_ other values (i.e. int32_t
or uint32_t) via kconfig when necessary for older / smaller platforms.


But not POSIX 2024 compliant.  We have forbid non-compliant options in 
the past.  The option would basic say "Select to make NuttX 
non-compliant with POSIX."  We don't usually allow that kind of option; 
many useful Kconfig options have been removed just that reason.  Since 
the size of time_t is 64-bits in all cases, I think we have to comply.




Re: Change time_t to signed type

2024-11-07 Thread Tomek CEDRO
On Wed, Nov 6, 2024 at 2:11 PM Gregory Nutt  wrote:
> Here are solutions and details of implementations as implemented by
> other OSs and file systems (the year 2038 problem does apply to
> timestamps and meta-data in file systems too!  Including NFS). See
> https://en.wikipedia.org/wiki/Year_2038_problem
>
>   Implemented solutions
>
>   * Starting with Ruby
>  version
> 1.9.2 (released on 18 August 2010), the bug with year 2038 is
> fixed,^[16]
>  by
> storing time in a signed 64-bit integer on systems with 32-bit
> |time_t|.^[17]
> 
>   * Starting with NetBSD  version
> 6.0 (released in October 2012), the NetBSD operating system uses a
> 64-bit |time_t| for both 32-bit and 64-bit architectures.
> Applications that were compiled for an older NetBSD release with
> 32-bit |time_t| are supported via a binary compatibility layer, but
> such older applications will still suffer from the Y2038
> problem.^[18]
> 
>   * OpenBSD  since version 5.5,
> released in May 2014, also uses a 64-bit |time_t| for both 32-bit
> and 64-bit architectures. In contrast to NetBSD
> , there is no binary
> compatibility layer. Therefore, applications expecting a 32-bit
> |time_t| and applications using anything different from |time_t| to
> store time values may break.^[19]
> 
>   * Linux  originally used a 64-bit
> |time_t| for 64-bit architectures only; the pure 32-bit ABI
>  was not
> changed due to backward compatibility.^[20]
> 
> 
> Starting with version 5.6
> 
> 
> of 2020, 64-bit |time_t| is supported on 32-bit architectures, too.
> This was done primarily for the sake of embedded Linux
> 
> systems.^[21]
> 
>   * GNU C Library  since
> version 2.34 (released August 2021), added support for using 64-bit
> |time_t| on 32-bit platforms with appropriate Linux versions. This
> support can be activated by defining preprocessor macro |_TIME_BITS|
> to |64| when compiling source code.^[22]
> 
>   * FreeBSD  uses 64-bit |time_t|
> for all 32-bit and 64-bit architectures except 32-bit i386, which
> uses signed 32-bit |time_t| instead.^[23]
> 
>   * The x32 ABI  for Linux (which
> defines an environment for programs with 32-bit addresses but
> running the processor in 64-bit mode) uses a 64-bit |time_t|. Since
> it was a new environment, there was no need for special
> compatibility precautions.^[20]
> 
> 
>
>   * Network File System
>  version 4 has
> defined its time fields as |struct nfstime4 {int64_t seconds;
> uint32_t nseconds;}| since December 2000.^[24]
> 
> Version 3 supports unsigned 32-bit values as |struct nfstime3
> {uint32 seconds; uint32 nseconds;};|.^[25]
> 
> Values greater than zero for the seconds field denote dates after
> the 0-hour, January 1, 1970. Values less than zero for the seconds
> field denote dates before the 0-hour, January 1, 1970. In both
> cases, the nseconds (nanoseconds) field is to be added to the
> seconds field for the final time representation.
>   * The ext4  filesystem, when used
> with inode sizes larger than 128 bytes, has an extra 32-bit field
> per timestamp, of which 30 bits are used for the nanoseconds part of
> the timestamp, and the other 2 bits are used to extend the timestamp
> range to the year 2446.^[26]
> 
>   * The XFS  filesystem, starting
> with Linux 5.10, has an optional "big timestamps" feature which
> extends the timestamp r

Re: Change time_t to signed type

2024-11-07 Thread Gregory Nutt

On 11/7/2024 10:59 AM, Tomek CEDRO wrote:

Does adding kconfig's configurable time_t with uint32_t default
(as-is) with option to change int32_t and int64_t sounds good? Should
we use manual selection only or auto-detection (i.e. int64_t on 64-bit
archs)? :-)


 /Initial Response /

Not really.  The POSIX specification for time_t is still under work.  
Just changing the type to int64_t  is one likely result amongst others.  
I would not invest the effort in the timing calculations for an 
arbitrary non-standard solution.  I would wait for the specification to 
be released and not waste effort guessing what the standard will be.


   "In a future version of this volume of POSIX.1-2017, *time_t* is
   likely to be required to be capable of representing times far in the
   future. Whether this will be mandated as a 64-bit type or a
   requirement that a specific date in the future be representable (for
   example, 1 AD) is not yet determined. Systems purchased after
   the approval of this volume of POSIX.1-2017 should be evaluated to
   determine whether their lifetime will extend past 2038."
   https://pubs.opengroup.org/onlinepubs/9699919799/functions/time.html

If you are a gambling man and don't mind the risk of re-working time_t 
related logic, then I would bet on the type being int64_t as you are 
advocating.  What will be the units of time?  Still 1 sec?  Probably 
not.  Perhaps time_t will become a structure?  We don't really know.  
int64_t is not a bad bet but not substantiated by specification yet either.



This provides backward compatibility, easy configuration versatility /
fine tuning, and we may change the default when new POSIX standard is
ratified? :-)


Which might be a big job and might make all of that non-standard, 
unspecified implementation throw-away code.If someone wants to go 
through that effort and verify/fix all of the timing calculation 
functions as needed to support int54_t time_t, I would not oppose that.


 /LATER /

*/Never mind/*. POSIX 2024 has just been released and time_t is now 
required to be 64-bits. Lots and lots of other changes as well.


 * https://sortix.org/blog/posix-2024/

   The 2038 32-bit |time_t| apocalypse has been canceled to contain
   SCP-8601 .

 * 
https://www.reddit.com/r/C_Programming/comments/1e2ac63/new_features_for_c_in_posix_2024/?rdt=50686

   |time_t| is now required to be 64-bit. Farewell year 2038 problem.

I have seen on these POSIX summaries and would really like to see the 
language of the actual spec. At any rate, will a solid basis in 
specifications. I now agree with you. time_t must 64 bits on all 
platforms and with all tools.


Re: Change time_t to signed type

2024-11-07 Thread Tomek CEDRO
On Thu, Nov 7, 2024 at 4:38 PM Gregory Nutt  wrote:
> > On 11/7/2024 12:57 AM, Takashi Yamamoto wrote:
> >> my suggestion is to keep our time_t unsigned for now and revisit
> >> when/if we solve the issues of targets w/o 64-bit integers.
> >> (either by improving the toolchains, or stop supporting those targets,
> >> or inventing a way to workaround the year 2038 issue.)
> > That is a good decision too.  Remember that with using uint32_t as
> > NuttX always has, there is no year 2038 issue.  That issue would only
> > occur if we go to int32_t which has one bit less of range.
>
> The best reasons for leaving time_t as it is currently defined are:
>
>   * We don't have a year 2038 that needs to be solved (unless we
> introduce it)
>   * The POSIX committee is currently working on the new time definition
> to avoid the year 2038 problem.  And definition we invent ourselves
> now will need to be changed again when the newer POSIX standard is
> released.
>
> I have seen discussions of increasing the width of time_t AND adding
> higher resolution timing (milleseconds or microseconds instead of the
> seconds since the epoch).
>
> Changing the type of time_t will likely require re-work of many of the
> internal time computations, especially if the time unit changes.

Does adding kconfig's configurable time_t with uint32_t default
(as-is) with option to change int32_t and int64_t sounds good? Should
we use manual selection only or auto-detection (i.e. int64_t on 64-bit
archs)? :-)

This provides backward compatibility, easy configuration versatility /
fine tuning, and we may change the default when new POSIX standard is
ratified? :-)

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info


Re: Change time_t to signed type

2024-11-07 Thread Gregory Nutt

On 11/7/2024 5:00 AM, michal.lyszc...@bofc.pl wrote:

Having code we know is going to crap out in the near future is kinda strange
design choice. I think you could have ignored it when there was 50 years left,
but this will happen in 14 years which is not that far for embedded systems
that can work for decades.
Just to be clear, there is no year 2038 problem in the existing code 
that uses the uint32_t definition for time_t.  The problem would be 
introduced if we changed this to a int32_t type.  We currently have a 
year 2106 problem which is not so pressing.  We have 82 years left.






Re: Change time_t to signed type

2024-11-07 Thread Gregory Nutt




On 11/7/2024 12:57 AM, Takashi Yamamoto wrote:

my suggestion is to keep our time_t unsigned for now and revisit
when/if we solve the issues of targets w/o 64-bit integers.
(either by improving the toolchains, or stop supporting those targets,
or inventing a way to workaround the year 2038 issue.)
That is a good decision too.  Remember that with using uint32_t as 
NuttX always has, there is no year 2038 issue.  That issue would only 
occur if we go to int32_t which has one bit less of range.


The best reasons for leaving time_t as it is currently defined are:

 * We don't have a year 2038 that needs to be solved (unless we
   introduce it)
 * The POSIX committee is currently working on the new time definition
   to avoid the year 2038 problem.  And definition we invent ourselves
   now will need to be changed again when the newer POSIX standard is
   released.

I have seen discussions of increasing the width of time_t AND adding 
higher resolution timing (milleseconds or microseconds instead of the 
seconds since the epoch).


Changing the type of time_t will likely require re-work of many of the 
internal time computations, especially if the time unit changes.


Re: Change time_t to signed type

2024-11-07 Thread Gregory Nutt



On 11/7/2024 12:57 AM, Takashi Yamamoto wrote:

my suggestion is to keep our time_t unsigned for now and revisit
when/if we solve the issues of targets w/o 64-bit integers.
(either by improving the toolchains, or stop supporting those targets,
or inventing a way to workaround the year 2038 issue.)
That is a good decision too.  Remember that with using uint32_t as NuttX 
always has, there is no year 2038 issue.  That issue would only occur if 
we go to int32_t which has one bit less of range.


Re: Change time_t to signed type

2024-11-07 Thread Tomek CEDRO
On Thu, Nov 7, 2024 at 7:57 AM Takashi Yamamoto
 wrote:
> On Wed, Nov 6, 2024 at 6:52 PM Tomek CEDRO  wrote:
> > On Wed, Nov 6, 2024 at 5:21 AM Takashi Yamamoto
> >  wrote:
> > > On Wed, Nov 6, 2024 at 1:05 PM Tomek CEDRO  wrote:
> > > > On Wed, Nov 6, 2024 at 4:45 AM Takashi Yamamoto
> > > >  wrote:
> > > > > On Wed, Nov 6, 2024 at 12:31 PM Gregory Nutt  
> > > > > wrote:
> > > > > > On 11/5/2024 9:18 PM, Takashi Yamamoto wrote:
> > > > > > > does that GCC have int64_t?
> > > > > > Yes, according to include/nuttx/compiler.h.
> > > > > > >> zNEO (z16) and z8 are no long supportable without ZDS-II.  Other 
> > > > > > >> z80s
> > > > > > >> don't work with common small compilers like SDCC anymore.
> > > > > > > i guess people who care these targets should express what they 
> > > > > > > want
> > > > > > > wrt this time_t discussion.
> > > > > > > eg.
> > > > > > > * drop 32-bit time_t and leave these targets broken
> > > > > > > * keep uint32_t time_t as a user-visible option
> > > > > > > * make it depend on CONFIG_HAVE_LONG_LONG or such
> > > > > > > * something else?
> > > > > > There is no usable toolchain for these CPUs.
> > > > > i suppose they still want to fix the situation sooner or later. either
> > > > > by fixing the toolchains and/or nuttx. right?
> > > > > i guess their opinions on this topic are particularly important
> > > > > because the rest of the community is probably ok with unconditional
> > > > > int64_t time_t.
> > > > Not really "unconditional" but user selectable option, so it will be
> > > > int64_t by default, but also easily changeable to (u)int32_t when
> > > > needed, what seems most universal and versatile solution? Are there
> > > > other options we don't see? :-)
> > > being universal and versatile is not necessarily a good thing.
> > > please remember that the main motivation to make it signed was to make
> > > it easier to port
> > > foreign applications to nuttx.
> > > having many options somehow contradicts the purpose.
> >
> > What best solution can you see here Takashi? :-)
>
> my suggestion is to keep our time_t unsigned for now and revisit
> when/if we solve the issues of targets w/o 64-bit integers.
> (either by improving the toolchains, or stop supporting those targets,
> or inventing a way to workaround the year 2038 issue.)

Looks like now is this time to make decisions :-)

We have no control over toolchains, these are external dependencies :-)

We should not stop supporting targets that were working and still can
work with not much effort :-)

The workaround for Y2038 is here - switch to int64_t - as proved by
long list of implementations provided by Greg :-)

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info


Re: Change time_t to signed type

2024-11-07 Thread Tomek CEDRO
On Thu, Nov 7, 2024 at 12:01 PM  wrote:
> On 2024-11-06 10:01:55, Nathan Hartman wrote:
> > I am +1 for a Kconfig.
> >
> > * or just make the default 64-bit on ALL systems, and if you are
> > trimming resources, you can make a judgment call whether to reduce it
> > to 32-bit
>
> I would say this.
>
> I believe defaults should be what works for majority of cases. Things to work
> is more important for things to be quick. People of different experience and
> knowledge uses this RTOS. A lot of people won't even notice performance hit
> from 64bit time, but they will surely notice weird time bugs.
>
> Having code we know is going to crap out in the near future is kinda strange
> design choice. I think you could have ignored it when there was 50 years left,
> but this will happen in 14 years which is not that far for embedded systems
> that can work for decades.

+1 :-)

int64_t time_t as default via kconfig with option to manually switch
to int32_t or uint32_t seems most versatile and no surprises :-)

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info


Re: Change time_t to signed type

2024-11-07 Thread michal . lyszczek
On 2024-11-06 10:01:55, Nathan Hartman wrote:
> I am +1 for a Kconfig.
> 
> * or just make the default 64-bit on ALL systems, and if you are
> trimming resources, you can make a judgment call whether to reduce it
> to 32-bit

I would say this.

I believe defaults should be what works for majority of cases. Things to work
is more important for things to be quick. People of different experience and
knowledge uses this RTOS. A lot of people won't even notice performance hit
from 64bit time, but they will surely notice weird time bugs.

Having code we know is going to crap out in the near future is kinda strange
design choice. I think you could have ignored it when there was 50 years left,
but this will happen in 14 years which is not that far for embedded systems
that can work for decades.

-- 
.-.---.--.-.
| Michal Lyszczek | Embedded C, Linux |   Company Address|  .-. opensource |
| +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 |  oo|  supporter |
| https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\  & |
| GPG FF1EBFE7E3A974B1 | Bits of Code | NIP:   813 349 58 78 |(\_;/) programer |
`--^--^--^-'


signature.asc
Description: PGP signature


Re: Change time_t to signed type

2024-11-06 Thread Nathan Hartman
Thank you, Greg, for doing this research and putting this all together here!

This stood out (replying below):

On Wed, Nov 6, 2024 at 8:11 AM Gregory Nutt  wrote:
>   * Linux  originally used a 64-bit
> |time_t| for 64-bit architectures only; the pure 32-bit ABI
>  was not
> changed due to backward compatibility.^[20]
> 
> 
> Starting with version 5.6
> 
> 
> of 2020, 64-bit |time_t| is supported on 32-bit architectures, too.
> This was done primarily for the sake of embedded Linux
> 
> systems.^[21]

So, Linux (since 5.6) uses 64-bit time_t on 32-bit archs -- emphasis
on "primarily for the sake of embedded Linux systems" -- It sounds
like that was done because embedded systems are expected to function
in machinery, infrastructure, etc., things that are long-lived. This
is exactly my experience with embedded systems. So we need to be
mindful of Year 2038 problems.

I'd like to also reply to raiden00pl:

On Wed, Nov 6, 2024 at 6:20 AM raiden00pl  wrote:
>
> Unconditional int64_t time_t is a waste of resources for small systems.
> Easier porting of *some* applications for *some* users at the expense of
> other users is not the solution.
> Nuttx has a lot of options anyway and that is nothing more than a
> consequence of `INVIOLABLES.md`.
> For some people this is a disadvantage, for others it's a great opportunity
> to fine tune their system.
> Kconfig with choices, as Tomek says, seems like a good option to me. Next
> we can make the default
> value dependent on DEFAULT_SMALL. But whether the default 32 bit time
> should be signed or unsigned,
> I have no opinion.

This is very similar to my thoughts. It is good that we have Kconfig
and developers can fine-tune their systems to their needs and
constraints. In general, I think our defaults should make it as easy
as possible to get up-and-running, but we should give developers
options (through Kconfig) because they know best what they are trying
to achieve with NuttX.

I am +1 for a Kconfig.

I am okay with any of these possibilities:
* make the default depend on DEFAULT_SMALL like raiden00pl suggests
* or make the default 64-bit on all 32-bit and 64-bit systems and
32-bit on all 8-bit and 16-bit systems
* or just make the default 64-bit on ALL systems, and if you are
trimming resources, you can make a judgment call whether to reduce it
to 32-bit

Example where it makes sense to reduce time_t, even though Year 2038
problem: a toaster with a 8-bit MCU. As long as you implement time
comparisons to work correctly through rollover, your bread will come
out toasted correctly! Same for coffee maker, dishwasher, etc.

Cheers,
Nathan


Re: Change time_t to signed type

2024-11-06 Thread Gregory Nutt
Here are solutions and details of implementations as implemented by 
other OSs and file systems (the year 2038 problem does apply to 
timestamps and meta-data in file systems too!  Including NFS). See 
https://en.wikipedia.org/wiki/Year_2038_problem



 Implemented solutions

 * Starting with Ruby
    version
   1.9.2 (released on 18 August 2010), the bug with year 2038 is
   fixed,^[16]
    by
   storing time in a signed 64-bit integer on systems with 32-bit
   |time_t|.^[17]
   
 * Starting with NetBSD  version
   6.0 (released in October 2012), the NetBSD operating system uses a
   64-bit |time_t| for both 32-bit and 64-bit architectures.
   Applications that were compiled for an older NetBSD release with
   32-bit |time_t| are supported via a binary compatibility layer, but
   such older applications will still suffer from the Y2038
   problem.^[18]
   
 * OpenBSD  since version 5.5,
   released in May 2014, also uses a 64-bit |time_t| for both 32-bit
   and 64-bit architectures. In contrast to NetBSD
   , there is no binary
   compatibility layer. Therefore, applications expecting a 32-bit
   |time_t| and applications using anything different from |time_t| to
   store time values may break.^[19]
   
 * Linux  originally used a 64-bit
   |time_t| for 64-bit architectures only; the pure 32-bit ABI
    was not
   changed due to backward compatibility.^[20]
   
   Starting with version 5.6
   
   of 2020, 64-bit |time_t| is supported on 32-bit architectures, too.
   This was done primarily for the sake of embedded Linux
   
   systems.^[21]
   
 * GNU C Library  since
   version 2.34 (released August 2021), added support for using 64-bit
   |time_t| on 32-bit platforms with appropriate Linux versions. This
   support can be activated by defining preprocessor macro |_TIME_BITS|
   to |64| when compiling source code.^[22]
   
 * FreeBSD  uses 64-bit |time_t|
   for all 32-bit and 64-bit architectures except 32-bit i386, which
   uses signed 32-bit |time_t| instead.^[23]
   
 * The x32 ABI  for Linux (which
   defines an environment for programs with 32-bit addresses but
   running the processor in 64-bit mode) uses a 64-bit |time_t|. Since
   it was a new environment, there was no need for special
   compatibility precautions.^[20]
   

 * Network File System
    version 4 has
   defined its time fields as |struct nfstime4 {int64_t seconds;
   uint32_t nseconds;}| since December 2000.^[24]
   
   Version 3 supports unsigned 32-bit values as |struct nfstime3
   {uint32 seconds; uint32 nseconds;};|.^[25]
   
   Values greater than zero for the seconds field denote dates after
   the 0-hour, January 1, 1970. Values less than zero for the seconds
   field denote dates before the 0-hour, January 1, 1970. In both
   cases, the nseconds (nanoseconds) field is to be added to the
   seconds field for the final time representation.
 * The ext4  filesystem, when used
   with inode sizes larger than 128 bytes, has an extra 32-bit field
   per timestamp, of which 30 bits are used for the nanoseconds part of
   the timestamp, and the other 2 bits are used to extend the timestamp
   range to the year 2446.^[26]
   
 * The XFS  filesystem, starting
   with Linux 5.10, has an optional "big timestamps" feature which
   extends the timestamp range to the year 2486.^[27]
   
 * While the native APIs of OpenVMS
    can support timestamps up to
   31 July 31086,^[28]
   


Re: Change time_t to signed type

2024-11-05 Thread Takashi Yamamoto
On Wed, Nov 6, 2024 at 12:31 PM Gregory Nutt  wrote:
>
>
> On 11/5/2024 9:18 PM, Takashi Yamamoto wrote:
> > does that GCC have int64_t?
> Yes, according to include/nuttx/compiler.h.
> >
> >> zNEO (z16) and z8 are no long supportable without ZDS-II.  Other z80s
> >> don't work with common small compilers like SDCC anymore.
> > i guess people who care these targets should express what they want
> > wrt this time_t discussion.
> > eg.
> > * drop 32-bit time_t and leave these targets broken
> > * keep uint32_t time_t as a user-visible option
> > * make it depend on CONFIG_HAVE_LONG_LONG or such
> > * something else?
>
> There is no usable toolchain for these CPUs.

i suppose they still want to fix the situation sooner or later. either
by fixing the toolchains and/or nuttx. right?
i guess their opinions on this topic are particularly important
because the rest of the community is probably ok with unconditional
int64_t time_t.


Re: Change time_t to signed type

2024-11-05 Thread Gregory Nutt



On 11/5/2024 9:18 PM, Takashi Yamamoto wrote:

does that GCC have int64_t?

Yes, according to include/nuttx/compiler.h.



zNEO (z16) and z8 are no long supportable without ZDS-II.  Other z80s
don't work with common small compilers like SDCC anymore.

i guess people who care these targets should express what they want
wrt this time_t discussion.
eg.
* drop 32-bit time_t and leave these targets broken
* keep uint32_t time_t as a user-visible option
* make it depend on CONFIG_HAVE_LONG_LONG or such
* something else?


There is no usable toolchain for these CPUs.




Re: Change time_t to signed type

2024-11-05 Thread Takashi Yamamoto
On Wed, Nov 6, 2024 at 11:47 AM Gregory Nutt  wrote:
>
>
> On 11/5/2024 8:35 PM, Byron Ellacott wrote:
> > Hi Takashi,
> >
> >> ideally, we should use int64_t for all targets unconditionally, IMO.
> >> however, in practice, 64-bit integers don't seem available for some of
> >> our targets. (ez80, z8, z16)
> >> maybe someone can add 64-bit integer support to their toolchains. but
> >> i suppose we don't want to wait for it to happen.
> >>
> > No, you wouldn't want to wait for that, it's highly unlikely that ZDS-II
> > will ever get a substantial update and the community compiler options
> > all have their own issues and limitations. Much as I'd love to say that the
> > unofficial (e)Z80 clang target solves all problems, it's a few major
> > versions behind llvm now and my ELF patch for it is likewise not current -
> > it'd be a bit of effort for someone to actually use this option.
>
> ZDS-II is no longer an option anyway.  Changes in function prototypes
> and definitions of data types has made ZDS-II unusable (and that is
> really probably OK).  Recent eZ80 builds have used an experimental
> version of GCC.

does that GCC have int64_t?

> zNEO (z16) and z8 are no long supportable without ZDS-II.  Other z80s
> don't work with common small compilers like SDCC anymore.

i guess people who care these targets should express what they want
wrt this time_t discussion.
eg.
* drop 32-bit time_t and leave these targets broken
* keep uint32_t time_t as a user-visible option
* make it depend on CONFIG_HAVE_LONG_LONG or such
* something else?


Re: Change time_t to signed type

2024-11-05 Thread Gregory Nutt


On 11/5/2024 8:35 PM, Byron Ellacott wrote:

Hi Takashi,


ideally, we should use int64_t for all targets unconditionally, IMO.
however, in practice, 64-bit integers don't seem available for some of
our targets. (ez80, z8, z16)
maybe someone can add 64-bit integer support to their toolchains. but
i suppose we don't want to wait for it to happen.


No, you wouldn't want to wait for that, it's highly unlikely that ZDS-II
will ever get a substantial update and the community compiler options
all have their own issues and limitations. Much as I'd love to say that the
unofficial (e)Z80 clang target solves all problems, it's a few major
versions behind llvm now and my ELF patch for it is likewise not current -
it'd be a bit of effort for someone to actually use this option.


ZDS-II is no longer an option anyway.  Changes in function prototypes 
and definitions of data types has made ZDS-II unusable (and that is 
really probably OK).  Recent eZ80 builds have used an experimental 
version of GCC.


zNEO (z16) and z8 are no long supportable without ZDS-II.  Other z80s 
don't work with common small compilers like SDCC anymore.


Re: Change time_t to signed type

2024-11-05 Thread Tomek CEDRO
Is it possible to create just a simple Kconfig list of choices like this?

int64_t time_t <-- default
int32_t time_t
uint32_t time_t

This should cover most use cases and give developer a choice on
smaller / older platforms right?

There will be no inconsistencies autodetections variants (whatever
hidden actions) nor dependencies on target platforms / toolchains just
a manual conscious simple choice by the developer in one single place
:-)

I guess there is no sense to add 16-bit types to the list?

And we will have one single place to add int128_t when RV128 shows up :-)

Would that meet everyone needs and expectations? Plus maybe some
visible initial configuration message what type is used :-)

Tomek




On Wed, Nov 6, 2024 at 3:18 AM Xiang Xiao  wrote:
>
> Yes, I prefer 64bit time_t to map to int64_t unconditionally, since 64bit
> time_t is seldom selected by NuttX supported boards now, and no 2038
> problem.
> For 32bit time_t, we can add a Kconfig to let the user select
> signed/unsigned and default to unsigned for compatibility reasons.
>
> On Wed, Nov 6, 2024 at 9:40 AM Takashi Yamamoto
>  wrote:
>
> > > 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.
> >
> > ideally, we should use int64_t for all targets unconditionally, IMO.
> > however, in practice, 64-bit integers don't seem available for some of
> > our targets. (ez80, z8, z16)
> > maybe someone can add 64-bit integer support to their toolchains. but
> > i suppose we don't want to wait for it to happen.
> >



-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info


Re: Change time_t to signed type

2024-11-05 Thread Byron Ellacott
Hi Takashi,

>
> ideally, we should use int64_t for all targets unconditionally, IMO.
> however, in practice, 64-bit integers don't seem available for some of
> our targets. (ez80, z8, z16)
> maybe someone can add 64-bit integer support to their toolchains. but
> i suppose we don't want to wait for it to happen.
>

No, you wouldn't want to wait for that, it's highly unlikely that ZDS-II
will ever get a substantial update and the community compiler options
all have their own issues and limitations. Much as I'd love to say that the
unofficial (e)Z80 clang target solves all problems, it's a few major
versions behind llvm now and my ELF patch for it is likewise not current -
it'd be a bit of effort for someone to actually use this option.

-- 
bje


Re: Change time_t to signed type

2024-11-05 Thread Xiang Xiao
Yes, I prefer 64bit time_t to map to int64_t unconditionally, since 64bit
time_t is seldom selected by NuttX supported boards now, and no 2038
problem.
For 32bit time_t, we can add a Kconfig to let the user select
signed/unsigned and default to unsigned for compatibility reasons.

On Wed, Nov 6, 2024 at 9:40 AM Takashi Yamamoto
 wrote:

> > 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.
>
> ideally, we should use int64_t for all targets unconditionally, IMO.
> however, in practice, 64-bit integers don't seem available for some of
> our targets. (ez80, z8, z16)
> maybe someone can add 64-bit integer support to their toolchains. but
> i suppose we don't want to wait for it to happen.
>


Re: Change time_t to signed type

2024-11-05 Thread Takashi Yamamoto
> 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.

ideally, we should use int64_t for all targets unconditionally, IMO.
however, in practice, 64-bit integers don't seem available for some of
our targets. (ez80, z8, z16)
maybe someone can add 64-bit integer support to their toolchains. but
i suppose we don't want to wait for it to happen.


Re: Change time_t to signed type

2024-11-05 Thread Byron Ellacott
Hi,

On Wed, Nov 6, 2024 at 7:13 AM Tomek CEDRO  wrote:

>
> Nathan you mentioned the 8-bit and 16-bit platforms to use 32-bit
> unsigned. That would imply "virtual" type not natively supported by
> platform. Do you know what is the penalty for using such types? Is it
> safe? Does it work on all compilers? Is it slow? if no, then maybe we
> could also use int64_t on 32-bit platforms? :-P
>

It's safe, widely supported by compilers, and "slow" in that multiple
instructions will be used to support the operation instead of just one, and
multiple registers will carry the value instead of just one.

There's a penalty for it, but it's not really straightforward. Considering
a Cortex-M0 based processor, arithmetic operations on 64-bit values will
usually just be two or three instructions instead of one (eg, UMULL+MLA for
a 64-bit multiply for one operand 32-bit or less, or UMULL+MLA+MLA for two
64-bit operands). The real penalty kicks in for function arguments, though.
The common ARM calling convention reserves only four 32-bit registers for
function arguments, so passing three 32-bit arguments is entirely in
registers but passing three 64-bit arguments will put two 32-bit words on
the stack. Similarly, only registers r0-r3 and r12 can be used freely while
r4-r11 must have their values preserved. A function doing almost anything
with a 64-bit value is likely to use more than five registers and will need
to push and pop values.

You can see the difference in compiled output for a 32-bit function doing a
* b + c and a 64-bit function doing the same here:
https://godbolt.org/z/8bKj6an4z

As it happens the ARMv7 instruction set is designed to handle 64-bit values
with a minimum of fuss. For giggles try changing the compiler used by
godbolt to AVR GCC, where 64-bit multiplication is implemented as a libcall
and the ABI requires that 18 or so registers get preserved by the callee if
their contents can't be guaranteed to be non-volatile.

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.

-- 
Byron


Re: Change time_t to signed type

2024-11-05 Thread Tomek CEDRO
On Tue, Nov 5, 2024 at 9:46 PM Nathan Hartman  wrote:
>
> On Tue, Nov 5, 2024 at 3:07 PM Tomek CEDRO  wrote:
> >
> > Yet another (probably silly) idea: how about giving choice if 32
> > and/or 64 bit time is signed or unsigned in the kconfig and the
> > summary warning at the end of build? This way developers could select
> > what they want to use?
>
> This could give developers complete control, if they want something
> different than what we decide. But, which would be default? On 32-bit
> and 64-bit archs, I suggest to use the 64 bit signed type as default.
> On 8-bit and 16-bit archs, I suggest to use 32-bit unsigned as
> default. Developers who want something different can choose whichever
> combo they want.
>
> The ---help--- text for 32-bit signed should contain a WARNING: Your
> product will have a year 2038 problem if you choose this option!
>
> Also, I think we had a Kconfig in the past to choose the epoch. Is
> this still possible? Perhaps developers who never expect to deal with
> dates before the product release (e.g., 2024) could set the epoch to
> 01-01-2024 and use a 32-bit type? Various functions in the OS might
> have to be updated to accommodate such a Kconfig.

Okay so summing up all the problems and solutions this may be common
denominator:
1. Kconfig selectable `uint32_t time_t` as default on <= 32-bit
targets, can be changed to `int32_t time_t`.
2. Kconfig selectable `int64_t time_t` as default on 64-bit targets,
can be changed to `uint64_t time_t`.
3. Casting to (int) on time comparison + patching code / upstreams.

There is an inconsistency, but there is a choice.

Nathan you mentioned the 8-bit and 16-bit platforms to use 32-bit
unsigned. That would imply "virtual" type not natively supported by
platform. Do you know what is the penalty for using such types? Is it
safe? Does it work on all compilers? Is it slow? if no, then maybe we
could also use int64_t on 32-bit platforms? :-P

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info


Re: Change time_t to signed type

2024-11-05 Thread Nathan Hartman
On Tue, Nov 5, 2024 at 3:07 PM Tomek CEDRO  wrote:
>
> Yet another (probably silly) idea: how about giving choice if 32
> and/or 64 bit time is signed or unsigned in the kconfig and the
> summary warning at the end of build? This way developers could select
> what they want to use?

This could give developers complete control, if they want something
different than what we decide. But, which would be default? On 32-bit
and 64-bit archs, I suggest to use the 64 bit signed type as default.
On 8-bit and 16-bit archs, I suggest to use 32-bit unsigned as
default. Developers who want something different can choose whichever
combo they want.

The ---help--- text for 32-bit signed should contain a WARNING: Your
product will have a year 2038 problem if you choose this option!

Also, I think we had a Kconfig in the past to choose the epoch. Is
this still possible? Perhaps developers who never expect to deal with
dates before the product release (e.g., 2024) could set the epoch to
01-01-2024 and use a 32-bit type? Various functions in the OS might
have to be updated to accommodate such a Kconfig.

Cheers,
Nathan


Re: Change time_t to signed type

2024-11-05 Thread Tomek CEDRO
Yet another (probably silly) idea: how about giving choice if 32
and/or 64 bit time is signed or unsigned in the kconfig and the
summary warning at the end of build? This way developers could select
what they want to use?

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info


Re: Change time_t to signed type

2024-11-05 Thread Sebastien Lorquet

Hi,

the problem you demonstrate exists in the code below, but it's a coding 
bug. it's missing the signed cast to compare wrapping variables.


It is well known that to compare counters that can rollover/wrap, the 
subtraction to check if the timer has elapsed *must* be using signed 
arithmetic.


The usual case is hardware timers, which are most always considered 
unsigned. This is not just a Nuttx problem.


https://stackoverflow.com/questions/3095623/how-to-deal-with-a-wrapping-counter-in-embedded-c

This cast is required, at least as an explicit acknowledge that the 
wrapping behaviour has been taken into consideration. I add comments 
every time I have to do this now. Of course I have been bitten by this 
bug too, in a bare metal PIC18 project IIRC.


So, forcing counters to be signed just to avoid a well known embedded 
development pitfall makes little sense to me.


The ability to use negative timestamps (even if probably not really 
useful but you never know) is a much more valid reason.



I still do not advise changing the signedness of time_t, the reason is 
to prevent unpredictability in projects *we are not even aware of*


But doing so on the 64-bit version of time_t is less critical because it 
avoids the y2038 problem.



Anyway, changing the signedness of such an important variable should 
have to be explicitly acknowledged by developers.


Maybe with a mechanism similar to debian updates that displays a text 
with important warnings from updated packages. That could be triggered 
by make.


Or maybe a kconfig option, something like that now must be checked 
before code compiles again:


#ifndef CONFIG_DEVELOPER_ACKNOWLEDGED_TIME_SIGNEDNESS_CHANGE
#error "Signedness of 64-bit time_t has changed, you may need to fix 
your code to take this change into account. Please do so, then select 
option CONFIG_DEVELOPER_ACKNOWLEDGED_TIME_SIGNEDNESS_CHANGE in kconfig 
(indicate where to find it) to acknowledge this fact."

#endif

We should make sure that every developer will be aware of it. Releases 
notes are not enough.


Thank you everyone for discussing these issues.

Sebastien


On 11/5/24 19:50, Xiang Xiao wrote:

Here is a simple example demonstrate that why the signed/unsigned is very
important for time_t:
one function records a timestamp:
time_t t1 = time(NULL);

another function records a second timestamp:
time_t t2 = time(NULL);

and check which one is early by:
if (t2 - t1 < 0)
   {
 printf("t2 is early than t1\n");
   }

But If time_t is an unsigned integer, the comparison can never become true:
https://devblogs.microsoft.com/oldnewthing/20140122-00/?p=2013
Since most POSIX OS map time_t to a signed type, the above code(appears in
many code bases) works very well until they meet NuttX.
Actually, we hit the problem before which takes our engineer to debug this
problem and find the root cause by several days.
That's why I prefer to follow other OS practice if the spec is ambiguous
like time_t.
If 32bit signed time_t is unacceptable due to the 2038 problem, at least
64bit time_t should change to the signed integer.
Otherwise, you will take time to debug the above problem soon or later.

On Tue, Nov 5, 2024 at 6:05 PM Simon Filgis 
wrote:


Thanks. So there are use cases for negative numbers of time. Interesting.


--
Hard- and Softwaredevelopment Consultant

Geschäftsführung: Simon Filgis
USt-IdNr.: DE305343278
ISO9001:2015 


On Tue, Nov 5, 2024 at 11:03 AM  wrote:


On 2024-11-05 08:13:19, Simon Filgis wrote:

Seems like a dump question, but why time needs to be signed?

It doesn't. But you may want to go backwards to show date before 1970.
This is
usually implemented by using negative time.

--



.-.---.--.-.

| Michal Lyszczek | Embedded C, Linux |   Company Address|  .-.
opensource |
| +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 |  oo|
supporter |
| https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\
& |
| GPG FF1EBFE7E3A974B1 | Bits of Code | NIP:   813 349 58 78 |(\_;/)
programer |



`--^--^--^-'


Re: Change time_t to signed type

2024-11-05 Thread Xiang Xiao
Here is a simple example demonstrate that why the signed/unsigned is very
important for time_t:
one function records a timestamp:
time_t t1 = time(NULL);

another function records a second timestamp:
time_t t2 = time(NULL);

and check which one is early by:
if (t2 - t1 < 0)
  {
printf("t2 is early than t1\n");
  }

But If time_t is an unsigned integer, the comparison can never become true:
https://devblogs.microsoft.com/oldnewthing/20140122-00/?p=2013
Since most POSIX OS map time_t to a signed type, the above code(appears in
many code bases) works very well until they meet NuttX.
Actually, we hit the problem before which takes our engineer to debug this
problem and find the root cause by several days.
That's why I prefer to follow other OS practice if the spec is ambiguous
like time_t.
If 32bit signed time_t is unacceptable due to the 2038 problem, at least
64bit time_t should change to the signed integer.
Otherwise, you will take time to debug the above problem soon or later.

On Tue, Nov 5, 2024 at 6:05 PM Simon Filgis 
wrote:

> Thanks. So there are use cases for negative numbers of time. Interesting.
>
>
> --
> Hard- and Softwaredevelopment Consultant
>
> Geschäftsführung: Simon Filgis
> USt-IdNr.: DE305343278
> ISO9001:2015 
>
>
> On Tue, Nov 5, 2024 at 11:03 AM  wrote:
>
> > On 2024-11-05 08:13:19, Simon Filgis wrote:
> > > Seems like a dump question, but why time needs to be signed?
> > It doesn't. But you may want to go backwards to show date before 1970.
> > This is
> > usually implemented by using negative time.
> >
> > --
> >
> >
> .-.---.--.-.
> > | Michal Lyszczek | Embedded C, Linux |   Company Address|  .-.
> > opensource |
> > | +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 |  oo|
> > supporter |
> > | https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\
> > & |
> > | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP:   813 349 58 78 |(\_;/)
> > programer |
> >
> >
> `--^--^--^-'
> >
>


Re: Change time_t to signed type

2024-11-05 Thread Simon Filgis
Thanks. So there are use cases for negative numbers of time. Interesting.


--
Hard- and Softwaredevelopment Consultant

Geschäftsführung: Simon Filgis
USt-IdNr.: DE305343278
ISO9001:2015 


On Tue, Nov 5, 2024 at 11:03 AM  wrote:

> On 2024-11-05 08:13:19, Simon Filgis wrote:
> > Seems like a dump question, but why time needs to be signed?
> It doesn't. But you may want to go backwards to show date before 1970.
> This is
> usually implemented by using negative time.
>
> --
>
> .-.---.--.-.
> | Michal Lyszczek | Embedded C, Linux |   Company Address|  .-.
> opensource |
> | +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 |  oo|
> supporter |
> | https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\
> & |
> | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP:   813 349 58 78 |(\_;/)
> programer |
>
> `--^--^--^-'
>


Re: Change time_t to signed type

2024-11-05 Thread michal . lyszczek
On 2024-11-05 08:13:19, Simon Filgis wrote:
> Seems like a dump question, but why time needs to be signed?
It doesn't. But you may want to go backwards to show date before 1970. This is
usually implemented by using negative time.

-- 
.-.---.--.-.
| Michal Lyszczek | Embedded C, Linux |   Company Address|  .-. opensource |
| +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 |  oo|  supporter |
| https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\  & |
| GPG FF1EBFE7E3A974B1 | Bits of Code | NIP:   813 349 58 78 |(\_;/) programer |
`--^--^--^-'


signature.asc
Description: PGP signature


Re: Change time_t to signed type

2024-11-05 Thread Alin Jerpelea
I think that we should focus on fixing the 2038 issue and maintain
compatibility with the existing code.
We should not postpone the fix until later or break the compatibility for
our users

Best regards
Alin

On Tue, Nov 5, 2024 at 8:08 AM Guiding Li  wrote:

> 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  于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
>> 
>> pubs.opengroup.org 
>> [image: favicon.ico] 
>> 
>>
>> 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 
>>  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
>>
>>


Re: Change time_t to signed type

2024-11-04 Thread Takashi Yamamoto
On Mon, Nov 4, 2024 at 10:33 PM Guiding Li  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) {

this example doesn't make sense without showing the type of getActiveTime.

> And we can find an reference on the official website:
>
> https://www.gnu.org/software/libc/manual/html_node/Time-Types.html

this is not "official" for nuttx.

>
> 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.

this is clearly wrong.

for this kind of announcements, it's far important to highlight disadvantages
than advantages, IMO.

i made references to the previous discussions on this topic i'm aware
of, up to this ML thread:
https://github.com/apache/nuttx/issues/3390#issuecomment-2456418833

> If there is any question about this, please let me know.
> Thanks,
> Guiding


Re: Change time_t to signed type

2024-11-04 Thread Simon Filgis
Seems like a dump question, but why time needs to be signed?

Guiding Li  schrieb am Di., 5. Nov. 2024, 08:08:

> 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  于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
>> 
>> pubs.opengroup.org 
>> [image: favicon.ico] 
>> 
>>
>> 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 
>>  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
>>
>>


Re: Change time_t to signed type

2024-11-04 Thread Guiding Li
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  于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
> 
> pubs.opengroup.org 
> [image: favicon.ico] 
> 
>
> 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 
>  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
>
>


Re: Change time_t to signed type

2024-11-04 Thread Xiang Xiao
It isn't only glibc, many other libc implementations(e.g. musl, newlib,
bionic) follow this convention.
I think 64bit time_t should be fine to change to signed integer, but keep
32bit time_t as before.

On Tue, Nov 5, 2024 at 4:51 AM  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
> 
> pubs.opengroup.org 
> [image: favicon.ico] 
> 
>
> 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  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
>
>


Re: Change time_t to signed type

2024-11-04 Thread Gregory Nutt
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 


pubs.opengroup.org 
favicon.ico 



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  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

Re: Change time_t to signed type

2024-11-04 Thread bje
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 8pubs.opengroup.orgGNU 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.  ByronOn 4 Nov 2024, at 11:33 PM, Guiding Li  wrote:Hi all:We decide change 'time_t' from unsigned type to signed type in PR:https://github.com/apache/nuttx/pull/14460Because when compile some POSIX library, there always be a warning oncomparisonbetween 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 ofinteger expressions of different signedness: 'long long int' and 'long longunsigned 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.htmlOn 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 docompare 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

Re: Change time_t to signed type

2024-11-04 Thread Sebastien Lorquet

Thank you Guiding Li to bring this issue to the attention of the list.

As said in the github issue, my only issue is: please warn the users 
that may be affected by this change in a way that is very visible for 
them, because this moves the last date from 2106 to 2038, changes how 
comparisons should be handled, and it's not always possible to move to 
64 bits timestamp easily.


Thats all.

Sebastien


On 04/11/2024 16:38, Sebastien Lorquet wrote:

What could possibly go wrong in existing apps, I wonder.

Changing the signedness of such an important variable to remove ONE 
warning at the risk of breaking NUMEROUS systems is insane.


Dont tell me everyone uses 64 bits. Many systems will still use 32 
bits for legacy reasons. Now if they update, you give them a year 2038 
problem that was not there before.


This is forcing everyone of those to migrate to 64 bit timestamps, 
which use doubles the field size.


DO NOT do this. Remove 32 bits support entirely, Changing the 
signedness of time is a huge risk that no one on this list can evaluate.


Sebastien

On 04/11/2024 14:32, Guiding Li 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



Re: Change time_t to signed type

2024-11-04 Thread Sebastien Lorquet

What could possibly go wrong in existing apps, I wonder.

Changing the signedness of such an important variable to remove ONE 
warning at the risk of breaking NUMEROUS systems is insane.


Dont tell me everyone uses 64 bits. Many systems will still use 32 bits 
for legacy reasons. Now if they update, you give them a year 2038 
problem that was not there before.


This is forcing everyone of those to migrate to 64 bit timestamps, which 
use doubles the field size.


DO NOT do this. Remove 32 bits support entirely, Changing the signedness 
of time is a huge risk that no one on this list can evaluate.


Sebastien

On 04/11/2024 14:32, Guiding Li 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