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 <m...@klomp.org> wrote: > Hi, > > On Sun, Nov 21, 2021 at 11:14:11PM +0100, Alexander Kanavin via > Elfutils-devel wrote: > > From: Alexander Kanavin <alex.kana...@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 >