Re: [PATCH] debuginfod/debuginfod-client.c: correct string format on 32bit arches with 64bit time_t

[Mark Wielaard <mark@klomp.org>]

Hi,

On Sun, Nov 21, 2021 at 11:14:11PM +0100, Alexander Kanavin via Elfutils-devel wrote:
> From: Alexander Kanavin <alex.kanavin@gmail.com>
> 
> Use intmax_t to print time_t
> 
> time_t is platform dependent and some of architectures e.g.
> x32, riscv32, arc use 64bit time_t even while they are 32bit
> architectures, therefore directly using integer printf formats will not
> work portably, use intmax_t to typecast time_t into printf family of
> functions.

OK, so there were some questions about whether using intmax_t and %jd
are portable enough, but I think it is clear that everything these
days support that. So that is good.

> musl 1.2.0 and above uses time64 on all platforms; glibc 2.34 has added support for
> time64 (which might be enabled by distro-wide CFLAGS), with possibly
> 2.35 or 2.36 making it enabled by default.
> 
> Use a plain int for scanning cache_config, as that's what the function
> returns.

So I think you are correct that printing/scanning/casting the time_t
around is somewhat unfortunate because the size of time_t is not
stable across architectures. Thanks for looking into this. I had no
idea time_t was such a problematic data type.

What makes it even more curious is that debuginfod_config_cache takes
a long, not a time_t, while it is always called with a time_t
argument. And then it returns an int... The result is interpreted as a
negative errno number or is cast back to a time_t if it is positive.

With this patch we write out the interval values "as big as possible"
(intmax_t), but read it back in "as small as possible" (int). Would it
make sense to also try to read it back in as intmax_t and then cast
down to int? Or simply always cast down to int before writing it out,
so reading and writing use the same data type?

We seem to not expect these intervals to be much bigger than a week,
so an int should always be big enough (even when stretched up to a
whole year).

Thanks,

Mark