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: 2024 November newsletter

Of course! Thank you for the support! :) Our internal goal for this week is to add 8 more NuttX projects to the project creator , to have 10 in total! Cheers, Gabor Tomek CEDRO ezt írta (időpont: 2024. nov. 4., H, 17:10): > NuttX mentioned :-) > > -- > Ce

Fwd: 2024 November newsletter

NuttX mentioned :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info -- Forwarded message - From: kisvegabor (LVGL) Date: Mon, Nov 4, 2024, 09:37 Subject: 2024 November newsletter Hey CeDeROM, How have you been recently? I have some exciting updates to share! 😊 *Project Creator

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

Re: What is the right way to add PM to esp32c6

Hi Felipe, good to hear about your progress here! These functions are ROM-defined functions. By checking the TRM, you can see a read-only flash partition that holds some functions (widely used functions, like malloc and internal functions). ets_get_cpu_frequency