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

[Alexander Kanavin <alex.kanavin@gmail.com>]

I'm not sure; the point of this patch is simply to ensure debuginfod builds
everywhere without errors. Making the types consistent is perhaps better
done as a followup?

Alex

On Sun, 5 Dec 2021 at 21:31, Mark Wielaard <mark@klomp.org> wrote:

> 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
>