Re: Let's remove Gnulib's ctime module

[Paul Eggert]

On 2024-02-09 07:00, Bruno Haible wrote:

> I agree that the majority of callers will use a time_t -> struct tm
> conversion first. But if we want to recommend an 'asctime' and 'asctime_r'
> replacement

We don't, because asctime is a bug magnet. Pretty much everybody who 
calls asctime calls localtime (or a relative) first, and almost 
everybody who does that neglects to check for localtime failure. It's a 
real mess, and we don't want to perpetuate the mess.

Much better to say: "just use ctime" (or some other substitute).


> We can't make it a locale_t because
>    - Some platforms don't have it:

That's OK. We provide a substitute "C_locale" that still works on these 
locales.

> 'true' is simpler than 'tzalloc (getenv ("TZ"))'.

It's not that much simpler than "localtime_tz", which is all callers 
need to know.

> > The migration is more complicated than that, since one must have 'if (s
> > != buf) free (s);' afterwards.
>
> Not in this case, because when i18n == false, the given format string
> cannot produce more than 64 characters.

Surely we don't want callers to be thinking about this sort of thing 
routinely. This complexity is not needed.

> Not everyone find it simple to write
>     (struct timespec) { .tv_sec = t, .tv_nsec = 0 }

First, you don't need the ", tv_nsec = 0". Second, if it's too painful 
to write (struct timespec) { .tv_sec = t } we can supply a simple inline 
function "tspec (t)" that converts t to a struct timespec. Such a 
function would be useful elsewhere, I expect.


> > In practice I don't think these buffers will overflow, as time strings
> > are short. So there's little need for malloc.
>
> One of the first occurrences that I found on codesearch.debian.net precisely
> used malloc.

I'm sure there will be a few callers that, for whatever reason, want to 
call malloc. That's OK; they can still do that. However, there's little 
reason for our functions to call malloc for them, because it's so rarely 
needed in practice when the buffers are so tiny, as they almost 
invariably are here.


> > If localtime_rz fails, this substitutes the decimal representation of T.
> > If the string doesn't fit this returns 0 and (if MAXSIZE is nonzero)
> > stores some truncation of the string into S.
>
> I vehemently disagree.

OK, then if localtime_rz fails, ctime/str_from_time/whatever can figure 
out the year number anyway, and generate the correct string. This isn't 
that hard to do. Then there will be no excuse for failure for large 
time_t values. (This is another reason we want to discourage asctime 
flavors; you cannot do this sort of thing with asctime.)


> local_tz would expand to a function call that caches the result,
> otherwise we have a memory leak.

Another possibility is that it could expand ((timezone_t) 1) and the 
rest of the code could treat this specially. This would also prevent the 
memory leak.