Paul Eggert wrote: > If you want to keep maintaining that TZ fix then let's keep the ctime > module. Still, Gnulib should not encourage ctime's use.
I agree on this. > > 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. I narrowed the interval, thinking of practical use-cases. Dates before 1582 are unlikely to occur anyway in the C locale, since the Gregorian calendar began only in that year. > > > That comment was not about SunOS. It was my attempt at understanding > > and documenting why ctime_r was still not adequate. I had written: > ... > That was wrong on two counts. First, POSIX ctime_r doesn't have a length > argument (though traditional SunOS ctime_r does). Oh, you are right. I had missed that there are two different APIs for ctime_r: the older Solaris one [1] and the POSIX one [2]. > > 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. I see, and I agree. > For now I installed the attached. Thanks; looks good. Bruno [1] https://docs.oracle.com/cd/E36784_01/html/E36874/ctime-r-3c.html [2] https://pubs.opengroup.org/onlinepubs/9699919799/functions/ctime.html
