From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b]) by sourceware.org (Postfix) with ESMTPS id 57F4C3858D28 for ; Sun, 5 Dec 2021 20:45:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 57F4C3858D28 Received: by mail-ua1-x92b.google.com with SMTP id p37so15801446uae.8 for ; Sun, 05 Dec 2021 12:45:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=753apMf9o067ALhSpeNTOVViLF8l1lfWgF68Eh17Rmg=; b=6x0iAMZbp4EKEAwDuv6xWtg9aRNr8G+A352OmiERU3WMQEEQoBz+8TnSFpjp41+uvl v+qwA5EVdLkiaKc3mOiZH1sx6r5WwHAw7PELG1oJvr9CHVMASkS4GZKW2IwX1M+6IH1e AinNAnGHKPcDZOyH5O16IkTWX4rdBjx1llzQDUVlx7aGGaJ11kfIXbnHi2qowJxrHgm8 ofbauxX68tXa7N5mzXfwSFd4Xb+/66GhY9pww7rJHxcY1uVfXudWqwVcZuwxksHp2gMi blCmUBCyyeZ8Jm2TXf+N1j5Y5PHSbW8kEpvjphWsw2XGaz5Q2ykzfSSS3nVaqO57q7fu 18og== X-Gm-Message-State: AOAM532KWjiVJrSWYUvHK4gmYPJ/c+IPRuobMYcGxyqCemS6zmSqZ21t 0UMB1HmjhS3ump4f4IwBp9eH4LBdEsQVjgBDj7Q= X-Google-Smtp-Source: ABdhPJxPUAjk8xYDqqU+dFqkSS8SKElJWchlxeeo0S1FwNN/MxYyX/KbNil29VmF3LBTXoci10caPbtoFprmirv4/0g= X-Received: by 2002:a9f:3e01:: with SMTP id o1mr35662403uai.89.1638737142947; Sun, 05 Dec 2021 12:45:42 -0800 (PST) MIME-Version: 1.0 References: <20211121221411.404194-1-alex@linutronix.de> In-Reply-To: From: Alexander Kanavin Date: Sun, 5 Dec 2021 21:45:31 +0100 Message-ID: Subject: Re: [PATCH] debuginfod/debuginfod-client.c: correct string format on 32bit arches with 64bit time_t To: Mark Wielaard Cc: elfutils-devel@sourceware.org, Khem Raj X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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:45:45 -0000 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 wrote: > 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 >