public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: "Érico Nogueira" <ericonr@disroot.org>
To: "Alexander Kanavin" <alex.kanavin@gmail.com>, <mark@klomp.org>,
	<elfutils-devel@sourceware.org>
Cc: "Khem Raj" <raj.khem@gmail.com>
Subject: Re: [PATCH] debuginfod/debuginfod-client.c: correct string format on 32bit arches with 64bit time_t
Date: Sat, 20 Nov 2021 00:57:52 -0300	[thread overview]
Message-ID: <CFUB08N95MDL.NTZCSEF65GGJ@mussels> (raw)
In-Reply-To: <20211119181524.3190417-1-alex@linutronix.de>

Hi!

On Fri Nov 19, 2021 at 3:15 PM -03, 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

For what it's worth, most of the time64 support patches that I have seen
use "%lld" and `long long` as the type for portable representation of
time, instead of intmax_t, but each should work just as well as the
other.

Might be worth mentioning in the commit that musl 1.2.0 and above uses
time64 on all platforms, and that 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.

>
> Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
> Signed-off-by: Khem Raj <raj.khem@gmail.com>
> ---
> debuginfod/debuginfod-client.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/debuginfod/debuginfod-client.c
> b/debuginfod/debuginfod-client.c
> index c875ee62..afd223b3 100644
> --- a/debuginfod/debuginfod-client.c
> +++ b/debuginfod/debuginfod-client.c
> @@ -231,7 +231,7 @@ debuginfod_config_cache(char *config_path,
> if (fd < 0)
> return -errno;
>  
> - if (dprintf(fd, "%ld", cache_config_default_s) < 0)
> + if (dprintf(fd, "%jd", (intmax_t)cache_config_default_s) < 0)
> return -errno;
> }
>  
> @@ -239,7 +239,7 @@ debuginfod_config_cache(char *config_path,
> FILE *config_file = fopen(config_path, "r");
> if (config_file)
> {
> - if (fscanf(config_file, "%ld", &cache_config) != 1)
> + if (fscanf(config_file, "%jd", (intmax_t*)(&cache_config)) != 1)

This is the wrong fix, a temporary variable should be used. When time_t
is still 32 bits, it means you can accidentally write out of bounds for
times after 2038 on little endian plaforms; and on big endian platforms,
it's always writing out of bounds (and *only out of bounds*, before
2038, so you can't even access the result of fscanf).

Having now taken a second look at the code, I don't think this needs to
be treated as time_t, anyway? cache_config is a `long`, and it's reading
a max timeout value, which is unlikely to go beyond the hundreds of
seconds... Given that the function returns an `int`, I'd even consider
making `cache_config` an `int` directly.

> cache_config = cache_config_default_s;
> fclose(config_file);
> }
> @@ -272,7 +272,7 @@ debuginfod_init_cache (char *cache_path, char
> *interval_path, char *maxage_path)
> if (fd < 0)
> return -errno;
>  
> - if (dprintf(fd, "%ld", cache_clean_default_interval_s) < 0)
> + if (dprintf(fd, "%jd", (intmax_t)cache_clean_default_interval_s) < 0)
> return -errno;
>  
> /* init max age config file. */
> @@ -280,7 +280,7 @@ debuginfod_init_cache (char *cache_path, char
> *interval_path, char *maxage_path)
> && (fd = open(maxage_path, O_CREAT | O_RDWR, DEFFILEMODE)) < 0)
> return -errno;
>  
> - if (dprintf(fd, "%ld", cache_default_max_unused_age_s) < 0)
> + if (dprintf(fd, "%jd", (intmax_t)cache_default_max_unused_age_s) < 0)
> return -errno;
>  
> return 0;
> --
> 2.20.1


  reply	other threads:[~2021-11-20  4:13 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-19 18:15 Alexander Kanavin
2021-11-20  3:57 ` Érico Nogueira [this message]
2021-11-20  8:11   ` Alexander Kanavin
2021-11-20 14:41     ` Khem Raj
2021-11-21 22:14 Alexander Kanavin
2021-11-25 17:51 ` Frank Ch. Eigler
2021-11-25 18:50   ` Alexander Kanavin
2021-11-25 19:24     ` Frank Ch. Eigler
2021-12-05 20:31 ` Mark Wielaard
2021-12-05 20:45   ` Alexander Kanavin
2021-12-08 15:31     ` Mark Wielaard
2021-12-09  9:52       ` Alexander Kanavin
2021-12-09  0:56   ` Frank Ch. Eigler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CFUB08N95MDL.NTZCSEF65GGJ@mussels \
    --to=ericonr@disroot.org \
    --cc=alex.kanavin@gmail.com \
    --cc=elfutils-devel@sourceware.org \
    --cc=mark@klomp.org \
    --cc=raj.khem@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).