Re: Let's remove Gnulib's ctime module

[Paul Eggert]

On 2024-02-10 02:33, Simon Josefsson wrote:

> 2) can we implement this in a way that it never fails?  I still allow
> return==NULL to indicate errors below, until we can confirm that it is
> possible to implement this in a way that cannot fail.  Returning "magic"
> values like "1970-01-01" seems worse than NULL to me, since then callers
> will need to do string comparisons to catch error situations.
Yes, we can do it without magic string values. Our ctime substitute can 
call localtime_r only with timestamps where the resulting tm_year must 
be in int range. For arguments outside that range it can first reduce 
the time_t argument to a reasonable range, call localtime_r on the 
resulting in-range time_t value (this is guaranteed to succeed), and 
calculate the correct year using time_t arithmetic (this is guaranteed 
to not overflow), and convert the resulting year to a string by hand.

> my goal is for this function to
> be a drop-in well-defined superset for ctime.
If I understand you correctly, what you want is merely a well-defined 
implementation of ctime_r. That is, whenever POSIX.1-2017 says the 
behavior is undefined, you want an implementation that has well-defined 
and obviously correct behavior. If so, that solves the problem of your 
next point:

> 5) Naming.
Let's just call this replacement function 'ctime_r', because that's what 
it is. It doesn't matter that POSIX is obsoleting ctime_r, as this 
function is intended for use only for obsoletish callers. And it doesn't 
matter if the system ctime_r has undefined behavior in some cases, as 
our replacement will merely extend it so that the behavior is well-defined.