All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Anand Jain <anand.jain@oracle.com>
Cc: fstests@vger.kernel.org, linux-btrfs@vger.kernel.org,
	linux-xfs@vger.kernel.org
Subject: Re: [PATCH] fstests: fix blksize_t printf format warnings across architectures
Date: Wed, 20 Nov 2024 08:28:24 -0800	[thread overview]
Message-ID: <20241120162824.GC9438@frogsfrogsfrogs> (raw)
In-Reply-To: <c4847cd94f86bd98fc563f112e177b317dc21111.1732102551.git.anand.jain@oracle.com>

On Wed, Nov 20, 2024 at 07:40:41PM +0800, Anand Jain wrote:
> Fix format string warnings when printing blksize_t values that vary
> across architectures. The warning occurs because blksize_t is defined
> differently between architectures: aarch64 architectures blksize_t is
> int, on x86-64 it's long-int.  Cast the values to long. Fixes warnings
> as below.
> 
>  seek_sanity_test.c:110:45: warning: format '%ld' expects argument of type
>  'long int', but argument 3 has type 'blksize_t' {aka 'int'}
> 
>  attr_replace_test.c:70:22: warning: format '%ld' expects argument of type
>  'long int', but argument 3 has type '__blksize_t' {aka 'int'}
> 
> Signed-off-by: Anand Jain <anand.jain@oracle.com>

I waded through a whole bunch of glibc typedef and macro crud and
discovered that on x64 it can even be long long.  I think.  There were
so many levels of indirection that I am not certain that my analysis was
correct. :(

However, I don't see any harm in explicitly casting to long.  Nobody has
yet come up with a 8GB fsblock filesystem, so we're ok for now. :P

Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>

--D

> ---
>  src/attr_replace_test.c | 2 +-
>  src/seek_sanity_test.c  | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/src/attr_replace_test.c b/src/attr_replace_test.c
> index 1218e7264c8f..5d560a633361 100644
> --- a/src/attr_replace_test.c
> +++ b/src/attr_replace_test.c
> @@ -67,7 +67,7 @@ int main(int argc, char *argv[])
>  	if (ret < 0) die();
>  	size = sbuf.st_blksize * 3 / 4;
>  	if (!size)
> -		fail("Invalid st_blksize(%ld)\n", sbuf.st_blksize);
> +		fail("Invalid st_blksize(%ld)\n", (long)sbuf.st_blksize);
>  	size = MIN(size, maxsize);
>  	value = malloc(size);
>  	if (!value)
> diff --git a/src/seek_sanity_test.c b/src/seek_sanity_test.c
> index a61ed3da9a8f..c5930357911f 100644
> --- a/src/seek_sanity_test.c
> +++ b/src/seek_sanity_test.c
> @@ -107,7 +107,7 @@ static int get_io_sizes(int fd)
>  		offset += pos ? 0 : 1;
>  	alloc_size = offset;
>  done:
> -	fprintf(stdout, "Allocation size: %ld\n", alloc_size);
> +	fprintf(stdout, "Allocation size: %ld\n", (long)alloc_size);
>  	return 0;
>  
>  fail:
> -- 
> 2.47.0
> 
> 

  reply	other threads:[~2024-11-20 16:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-20 11:40 [PATCH] fstests: fix blksize_t printf format warnings across architectures Anand Jain
2024-11-20 16:28 ` Darrick J. Wong [this message]
2024-11-21  2:04   ` Anand Jain
2024-11-20 22:06 ` Qu Wenruo
2024-11-20 22:21   ` Darrick J. Wong
2024-11-20 23:10     ` Qu Wenruo
2025-01-09 15:09 ` [GIT PULL] fstests: btrfs changes staged-20250109 Anand Jain

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=20241120162824.GC9438@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=anand.jain@oracle.com \
    --cc=fstests@vger.kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.