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

Sound Open Firmware - Liam Girdwood, Intel

https://www.youtube.com/watch?v=vwDoEumA1Mo NuttX mentioned :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: POSIX environ variable

>I think this is already done for a few group common things. This is what task_info_s in TLS does, it is the "process common information" field. So putting env there would work for the whole process. The name "TLS" here is a bit confusing, obviously the env data is shared by the process and all

Re: POSIX environ variable

On 11/5/2024 6:57 AM, Ville Juven wrote: For direct user level access, one option is to move tg_envp to TLS / task_info_s. This way the user could access the memory without boring a hole into the kernel. The same environ is used by all threads in a task group/process. If one thread changes t

Re: POSIX environ variable

For direct user level access, one option is to move tg_envp to TLS / task_info_s. This way the user could access the memory without boring a hole into the kernel. In KERNEL mode this issue is very simple; every process has its own instance of environ** anyway so there is no need to use TLS or a

Re: POSIX environ variable

On 11/5/2024 3:43 AM, Takashi Yamamoto wrote: i guess it's possible to implement it similarly to what we do for errno. eg. # define environ (*get_environ_ptr_ptr()) although it still isn't quite posix compatible, it might be good enough for many applications. d18be28c82a2a6d82115c8af19d/shel

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: POSIX environ variable

i guess it's possible to implement it similarly to what we do for errno. eg. # define environ (*get_environ_ptr_ptr()) although it still isn't quite posix compatible, it might be good enough for many applications. whatever approach we take, it probably requires some extra validations in the ker

POSIX environ variable

Hello, I am sorry if this was already discussed before. I could not find concrete information in the documentation or the mailing list history. According to POSIX specifications [1]: > The array is pointed to by the external variable environ, which is defined as: > > extern char **environ; But

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