From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id 210D53858D28 for ; Sun, 5 Dec 2021 20:31:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 210D53858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from reform (deer0x00.wildebeest.org [172.31.17.130]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id BD6EB300071C; Sun, 5 Dec 2021 21:31:12 +0100 (CET) Received: by reform (Postfix, from userid 1000) id EFE982E805DB; Sun, 5 Dec 2021 21:31:11 +0100 (CET) Date: Sun, 5 Dec 2021 21:31:11 +0100 From: Mark Wielaard To: Alexander Kanavin Cc: elfutils-devel@sourceware.org, Khem Raj Subject: Re: [PATCH] debuginfod/debuginfod-client.c: correct string format on 32bit arches with 64bit time_t Message-ID: References: <20211121221411.404194-1-alex@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211121221411.404194-1-alex@linutronix.de> X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Dec 2021 20:31:16 -0000 Hi, On Sun, Nov 21, 2021 at 11:14:11PM +0100, Alexander Kanavin via Elfutils-devel wrote: > From: Alexander Kanavin > > 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