linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Zeng Heng <zengheng4@huawei.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: <linux-xfs@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<djwong@kernel.org>
Subject: Re: [PATCH -next] xfs: remove "%Ld" which doesn't meet C standard
Date: Wed, 31 Aug 2022 10:01:00 +0800	[thread overview]
Message-ID: <274b54e3-d33b-b48d-011d-30a45c696db0@huawei.com> (raw)
In-Reply-To: <b19dd730-28f4-982d-2ae7-471e0c11db0e@sandeen.net>

You're right, I would take the opinion into v2 and loop you.


在 2022/8/30 22:51, Eric Sandeen 写道:
> On 8/30/22 8:54 AM, Zeng Heng wrote:
>> The "%Ld" specifier, which represents long long unsigned,
>> doesn't meet C language standard, and even more,
>> it makes people easily mistake with "%ld", which represent
>> long unsigned. So replace "%Ld" with "lld".
>>
>> Do the same with "%Lu".
>>
>> Signed-off-by: Zeng Heng <zengheng4@huawei.com>
> I think this probably makes sense, but there are many more instances of
> %Ld and %Lu in the xfs code, so why change just these 3?
>
> $ cd fs/xfs
> $ grep -r "%Lu\|%Ld" .
> ./libxfs/xfs_inode_fork.c:	"corrupt inode %Lu (bad size %d for local fork, size = %zd).",
> ./libxfs/xfs_inode_fork.c:		xfs_warn(mp, "corrupt inode %Lu (btree).",
> ./libxfs/xfs_bmap.c:				xfs_warn(mp, "%s: thispa(%d) == pp(%d) %Ld",
> ./xfs_inode.c:			"%s: Bad inode %Lu magic number 0x%x, ptr "PTR_FMT,
> ./xfs_inode.c:				"%s: Bad regular inode %Lu, ptr "PTR_FMT,
> ./xfs_inode.c:				"%s: Bad directory inode %Lu, ptr "PTR_FMT,
> ./xfs_inode.c:			"%s: bad inode %Lu, forkoff 0x%x, ptr "PTR_FMT,
> ./xfs_stats.c:	len += scnprintf(buf + len, PATH_MAX-len, "xpc %Lu %Lu %Lu\n",
> ./cscope/csdb:, "corrupt inode %Lu (btree).",
> ./cscope/csdb:", dino bp = "PTR_FMT", ino = %Ld",
> ./cscope/csdb:", ino %Ld",
> ./cscope/csdb:-len, "xpc %Lu %Lu %Lu\n",
> ./xfs_inode_item_recover.c:	"%s: Bad inode magic number, dip = "PTR_FMT", dino bp = "PTR_FMT", ino = %Ld",
> ./xfs_inode_item_recover.c:			"%s: Bad inode log record, rec ptr "PTR_FMT", ino %Ld",
>
>
>> ---
>>   fs/xfs/xfs_inode_item_recover.c | 4 ++--
>>   fs/xfs/xfs_stats.c              | 2 +-
>>   2 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/fs/xfs/xfs_inode_item_recover.c b/fs/xfs/xfs_inode_item_recover.c
>> index d28ffaebd067..0e5dba2343ea 100644
>> --- a/fs/xfs/xfs_inode_item_recover.c
>> +++ b/fs/xfs/xfs_inode_item_recover.c
>> @@ -321,7 +321,7 @@ xlog_recover_inode_commit_pass2(
>>   	 */
>>   	if (XFS_IS_CORRUPT(mp, !xfs_verify_magic16(bp, dip->di_magic))) {
>>   		xfs_alert(mp,
>> -	"%s: Bad inode magic number, dip = "PTR_FMT", dino bp = "PTR_FMT", ino = %Ld",
>> +	"%s: Bad inode magic number, dip = "PTR_FMT", dino bp = "PTR_FMT", ino = %lld",
>>   			__func__, dip, bp, in_f->ilf_ino);
>>   		error = -EFSCORRUPTED;
>>   		goto out_release;
>> @@ -329,7 +329,7 @@ xlog_recover_inode_commit_pass2(
>>   	ldip = item->ri_buf[1].i_addr;
>>   	if (XFS_IS_CORRUPT(mp, ldip->di_magic != XFS_DINODE_MAGIC)) {
>>   		xfs_alert(mp,
>> -			"%s: Bad inode log record, rec ptr "PTR_FMT", ino %Ld",
>> +			"%s: Bad inode log record, rec ptr "PTR_FMT", ino %lld",
>>   			__func__, item, in_f->ilf_ino);
>>   		error = -EFSCORRUPTED;
>>   		goto out_release;
>> diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c
>> index 70d38b77682b..90a77cd3ebad 100644
>> --- a/fs/xfs/xfs_stats.c
>> +++ b/fs/xfs/xfs_stats.c
>> @@ -74,7 +74,7 @@ int xfs_stats_format(struct xfsstats __percpu *stats, char *buf)
>>   		defer_relog += per_cpu_ptr(stats, i)->s.defer_relog;
>>   	}
>>   
>> -	len += scnprintf(buf + len, PATH_MAX-len, "xpc %Lu %Lu %Lu\n",
>> +	len += scnprintf(buf + len, PATH_MAX-len, "xpc %llu %llu %llu\n",
>>   			xs_xstrat_bytes, xs_write_bytes, xs_read_bytes);
>>   	len += scnprintf(buf + len, PATH_MAX-len, "defer_relog %llu\n",
>>   			defer_relog);

      reply	other threads:[~2022-08-31  2:01 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-30 13:54 [PATCH -next] xfs: remove "%Ld" which doesn't meet C standard Zeng Heng
2022-08-30 14:51 ` Eric Sandeen
2022-08-31  2:01   ` Zeng Heng [this message]

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=274b54e3-d33b-b48d-011d-30a45c696db0@huawei.com \
    --to=zengheng4@huawei.com \
    --cc=djwong@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sandeen@sandeen.net \
    /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 NNTP newsgroup(s).