Re: 32 bits time_t and Y2038 issue

On 14/03/2025 13:27, pozz wrote:

Il 13/03/2025 16:51, David Brown ha scritto:

On 13/03/2025 09:57, pozz wrote:

Il 12/03/2025 19:18, David Brown ha scritto:

On 12/03/2025 18:13, pozz wrote:

Ok, but I don't understand why you prefer to write your own code (yes, you're an exper programmer, but you can introduce some bugs, you have to write  some tests), while there are standard functions that make the job for you.
>

>
I prefer to use a newer version of the toolchain that does not have such problems :-)

 Sure, but the project is old. I will check if using a newer toolchain is a feasible solution for this project.
 

I fully appreciate - and agree with - not wanting to change toolchains on an existing established project.  It might be the best solution here, but it is certainly not one to be picked lightly.

 

I am quite happy to re-use known good standard functions.  There is no need to reinvent the wheel if you already have one conveniently available.  But you don't have standard functions conveniently available here - the ones from your toolchain are not up to the task, and you are not happy with the other sources you have found for the standard functions.
>
So once you have eliminated the possibility of using pre-written standard functions, you then need to re-evaluate what you actually need.   And that is much less than the standard functions provide.  So write your own versions to do what you need to do - no more, no less.

 I agree with you. I thought you were suggesting to use custom made functions in any case, because my approach that uses time_t counter (seconds from epoch) and localtime()/mktime() isn't good.
 

No.  I am merely saying that if you can't use the standard functions and have to get other ones from somewhere (or write them yourself), making them match standard function interfaces is of no benefit.  There are many alternative formats that could be better for your use.

 

2. Use an implementation from other library sources online.  You've ruled those out as too complicated.

 In the past I sometimes lurked in the newlib code and it seems too complicated for me. I will search for other simple implementations of localtime()/mktime().
 

There are other C standard libraries around - maybe others are better than newlib for this purpose.  (I don't know if newlib nano is mixed in with newlib here.)  Newlib sources are, at least in parts, a monstrosity of conditional compilation to support vast numbers of targets, compilers, OS's, and options.

 

3. Write your own functions.  Yes, that involves a certain amount of work, testing and risk.  That's your job.
>
Am I missing anything?

 I don't think.
 

I really hope you missed a word in that sentence :-)