On 2024-02-05 02:52, Simon Josefsson wrote:
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.
Yes, that code has undefined behavior for years outside the range [1000,
9999]. If the system clock must be in that year range, the code is OK
as-is. But since inetutils can be run on systems where the system clock
can be outside that range, it has undefined behavior when someone messes
with the system clock - something that I expect any attacker worth its
salt would want to add to its bag of tricks.
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
Yes, here ctime is used on a file timestamp, which is more problematic.
It's easy to give a file a timestamp outside the [1000, 9999] range:
touch -d@9223372036854775807 foo
so that part of inetutils has undefined behavior on such files. I think
glibc ctime dumps core on typical platforms, but we can't rely on that.
Overall, I'm not sure rewriting these to use sprintf/strftime is a clear
improvement, as the code would be uglier.
Hmm, well, part of the problem with ctime is that it's so *tempting* to
use its simple-but-buggy API. Really, the code needs to be changed.
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?
I would look askance at any Gnulib implementation of ctime that does
this sort of thing. The ctime API is so poorly designed that callers
should use some other API. This is partly why C23 is deprecating ctime.
Gnulib shouldn't encourage ctime's continued use.
Perhaps we could a new module c_nstrftime, which acts like nstrftime but
operates in the C locale. That should suffice to replace all uses of
ctime relatively easily.
