Re: Let's remove Gnulib's ctime module

[Paul Eggert]

On 2024-02-05 06:37, Bruno Haible wrote:

> I disagree that the ctime module is "a maintenance hassle". In my view,
> its maintenance takes much less effort than the average.

That depends on what we're averaging over. (Certainly over the past day 
it's been more than average. :-)


> Since my environment for native Windows is based on Cygwin (since that's
> generally more reliable than MSYS2) and the ctime problem with $TZ is a
> known one, I want to never encounter it again — even if I'm testing or
> debugging a package that happens to use ctime.

If you want to keep maintaining that TZ fix then let's keep the ctime 
module. Still, Gnulib should not encourage ctime's use.


> Also, according to your doc changes (which I'm mostly committing in your name),
> a program that makes sure to use ctime() only for dates between 1900 and
> 2100 is fine.

I think the range is [1000, 9999]; not sure where [1900, 2100] came from.


> That comment was not about SunOS. It was my attempt at understanding
> and documenting why ctime_r was still not adequate. I had written:

What you had written was a logical consequence of this earlier part  of 
the Gnulib manual:

> @code{ctime_r} takes a pre-allocated buffer and length of the buffer,
> and returns @code{NULL} on errors.

That was wrong on two counts. First, POSIX ctime_r doesn't have a length 
argument (though traditional SunOS ctime_r does). Second, POSIX ctime_r 
has undefined behavior on errors. Since what you wrote depended on an 
incorrect characterization of ctime_r, there seems little point to 
keeping it; as far as I know the comment is useful only on Solaris when 
_POSIX_PTHREAD_SEMANTICS is not defined, something that is impractical 
if Gnulib's 'extensions' module is used (which it should be).


> 26 bytes is not enough. But 50 should be enough. Can we give the advice
> that it's OK to invoke it with a buffer of size 50?

Heading in that direction would require testing/examination on various 
systems, some of which we lack source code for, and ctime_r is going 
away soon; surely it's not worth the effort.

If Gnulib-using code really needs a ctime substitute we should define 
one with a suitable API (e.g., c_nstrftime).

For now I installed the attached. Please feel free to resurrect the 
SunOS ctime_r commentary if you think it useful (but it should be 
labeled more clearly as being for Solaris).

0001-ctime-improve-doc.patch
Description: Text Data