On Thu, Nov 7, 2024 at 7:57 AM Takashi Yamamoto <yamam...@midokura.com.invalid> wrote: > On Wed, Nov 6, 2024 at 6:52 PM Tomek CEDRO <to...@cedro.info> wrote: > > On Wed, Nov 6, 2024 at 5:21 AM Takashi Yamamoto > > <yamam...@midokura.com.invalid> wrote: > > > On Wed, Nov 6, 2024 at 1:05 PM Tomek CEDRO <to...@cedro.info> wrote: > > > > On Wed, Nov 6, 2024 at 4:45 AM Takashi Yamamoto > > > > <yamam...@midokura.com.invalid> wrote: > > > > > On Wed, Nov 6, 2024 at 12:31 PM Gregory Nutt <spudan...@gmail.com> > > > > > 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
