Re: Change time_t to signed type

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

Re: Change time_t to signed type

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

Re: Change time_t to signed type

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-

Re: Change time_t to signed type

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

Re: Change time_t to signed type

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

Re: Change time_t to signed type

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_

Re: Change time_t to signed type

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 re

Re: Change time_t to signed type

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

Re: Change time_t to signed type

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 wor

Re: Change time_t to signed type

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 issu

Re: Change time_t to signed type

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

Re: Change time_t to signed type

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

Re: Change time_t to signed type

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

Re: Change time_t to signed type

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 o

Re: Change time_t to signed type

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

Re: Change time_t to signed type

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 R

Re: Change time_t to signed type

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 com

Re: Change time_t to signed type

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

Re: Change time_t to signed type

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

Re: Change time_t to signed type

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

Re: Change time_t to signed type

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

Re: Change time_t to signed type

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

Re: Change time_t to signed type

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

Re: Change time_t to signed type

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

Re: Change time_t to signed type

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 co

Re: Change time_t to signed type

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

Re: Change time_t to signed type

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

Re: Change time_t to signed type

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

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.

Re: Change time_t to signed type

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 ea

Re: Change time_t to signed type

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 20

Re: Change time_t to signed type

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

Re: Change time_t to signed type

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

Re: Change time_t to signed type

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

Re: Change time_t to signed type

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

Re: Change time_t to signed type

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

Re: Change time_t to signed type

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

Re: Change time_t to signed type

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 v

Re: Change time_t to signed type

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 extens

Re: Change time_t to signed type

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 sh

Re: Change time_t to signed type

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 upda

Change time_t to signed type

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