bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Let's remove Gnulib's ctime module


From: Simon Josefsson
Subject: Re: Let's remove Gnulib's ctime module
Date: Mon, 05 Feb 2024 11:52:10 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

Here are some examples of ctime usage in GNU InetUtils, starting with
inetd (a single-threaded application):

https://git.savannah.gnu.org/cgit/inetutils.git/tree/src/inetd.c?id=aba8d6528e2577eee7fafab3c418ee5bd94c096b#n1710

This prints day of time of the system.  While we could rewrite that to
use strftime, that would complicate the code to support years < 1000 and
years > 9999 as far as I understand.

Another one is in logger, also a single-threaded application:

https://git.savannah.gnu.org/cgit/inetutils.git/tree/src/logger.c?id=aba8d6528e2577eee7fafab3c418ee5bd94c096b#n301

The code discards day of week and year, but is otherwise okay for years
1000..9999.

Another one is in syslogd:

https://git.savannah.gnu.org/cgit/inetutils.git/tree/src/syslogd.c?id=aba8d6528e2577eee7fafab3c418ee5bd94c096b#n1211
https://git.savannah.gnu.org/cgit/inetutils.git/tree/src/syslogd.c?id=aba8d6528e2577eee7fafab3c418ee5bd94c096b#n1343

There is another use inside libls, which is a bit more interesting:

https://git.savannah.gnu.org/cgit/inetutils.git/tree/libls/print.c?id=aba8d6528e2577eee7fafab3c418ee5bd94c096b#n268

Overall, I'm not sure rewriting these to use sprintf/strftime is a clear
improvement, as the code would be uglier.  Maybe some wrapper will help.
I don't like having code that rely on or trigger undefined behaviour
though.

Could gnulib's ctime replacement call abort() when year<1000 or
year>9999?

Another idea is to have gnulib's ctime augment the C standard to have
ctime not be undefined but to return shorter and longer strings, which I
believe is still consistent with the C standard?

For example it would be permitted to return strings like "Wed Jun 30
21:49:08 623\n" or "Wed Jun 30 21:49:08 11147\n".

Callers will need to make sure they handle string lengths != 26 though,
but that could be documented for the gnulib replacement.

I think this solution make sense for these examples, and is somewhat
more in line with what the original wish may have been: "give me a
english-centric human string representation of this time_t value in a
known fixed format".

/Simon

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]