From: Markus Armbruster <armbru@redhat.com>
To: Thomas Huth <thuth@redhat.com>
Cc: AlexChen <alex.chen@huawei.com>,
lvivier@redhat.com, Paolo Bonzini <pbonzini@redhat.com>,
QEMU Trivial <qemu-trivial@nongnu.org>,
QEMU <qemu-devel@nongnu.org>
Subject: Re: [PATCH] qtest: Fix bad printf format specifiers
Date: Thu, 05 Nov 2020 09:19:58 +0100 [thread overview]
Message-ID: <877dr0rz9t.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <67eca43e-99ea-f2ce-5d9e-a9cb5c7a3a83@redhat.com> (Thomas Huth's message of "Wed, 4 Nov 2020 11:44:46 +0100")
Thomas Huth <thuth@redhat.com> writes:
> On 04/11/2020 11.23, AlexChen wrote:
>> We should use printf format specifier "%u" instead of "%d" for
>> argument of type "unsigned int".
>>
>> Reported-by: Euler Robot <euler.robot@huawei.com>
>> Signed-off-by: Alex Chen <alex.chen@huawei.com>
>> ---
>> tests/qtest/arm-cpu-features.c | 8 ++++----
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/tests/qtest/arm-cpu-features.c b/tests/qtest/arm-cpu-features.c
>> index d20094d5a7..bc681a95d5 100644
>> --- a/tests/qtest/arm-cpu-features.c
>> +++ b/tests/qtest/arm-cpu-features.c
>> @@ -536,7 +536,7 @@ static void test_query_cpu_model_expansion_kvm(const void *data)
>> if (kvm_supports_sve) {
>> g_assert(vls != 0);
>> max_vq = 64 - __builtin_clzll(vls);
>> - sprintf(max_name, "sve%d", max_vq * 128);
>> + sprintf(max_name, "sve%u", max_vq * 128);
>>
>> /* Enabling a supported length is of course fine. */
>> assert_sve_vls(qts, "host", vls, "{ %s: true }", max_name);
>> @@ -556,7 +556,7 @@ static void test_query_cpu_model_expansion_kvm(const void *data)
>> * unless all larger, supported vector lengths are also
>> * disabled.
>> */
>> - sprintf(name, "sve%d", vq * 128);
>> + sprintf(name, "sve%u", vq * 128);
>> error = g_strdup_printf("cannot disable %s", name);
>> assert_error(qts, "host", error,
>> "{ %s: true, %s: false }",
>> @@ -569,7 +569,7 @@ static void test_query_cpu_model_expansion_kvm(const void *data)
>> * we need at least one vector length enabled.
>> */
>> vq = __builtin_ffsll(vls);
>> - sprintf(name, "sve%d", vq * 128);
>> + sprintf(name, "sve%u", vq * 128);
>> error = g_strdup_printf("cannot disable %s", name);
>> assert_error(qts, "host", error, "{ %s: false }", name);
>> g_free(error);
>> @@ -581,7 +581,7 @@ static void test_query_cpu_model_expansion_kvm(const void *data)
>> }
>> }
>> if (vq <= SVE_MAX_VQ) {
>> - sprintf(name, "sve%d", vq * 128);
>> + sprintf(name, "sve%u", vq * 128);
>> error = g_strdup_printf("cannot enable %s", name);
>> assert_error(qts, "host", error, "{ %s: true }", name);
>> g_free(error);
>>
>
> max_vq and vq are both "uint32_t" and not "unsigned int" ... so if you want
Not quite. They are, but the product isn't. Assuming it is is actually
a common misconception of how C works.
C99 § 6.3.1.8 "Usual arithmetic conversions" applies. Short summary:
first, both operands of * undergo integer promotion (§ 6.3.1.1 Boolean,
characters, and integers), then we find a "common" integer type, convert
the operands to it, and multiply in that type.
128 is int (§ 6.4.4.1 Integer constants). Integer promotion does
nothing.
@vq is uint32_t per its declaration. If int can represent any uint32_t
value, it promotes to int; else if unsigned int can represent, it
promotes to unsigned int; else it stays the same.
In QEMU practice, "stays the same" is impossible, because unsigned int
narrower than 32 bits is. "Promotes to int" is unlikely, because int
wider than 32 bits is.
So, the "common" type is almost certainly unsigned int for us, but we
may want to do the right thing for the unlikely case of signed int.
It is uint32_t only when it's unsigned int, and the system makes
uint32_t an alias for unsigned int, say with typedef unsigned uint32_t.
> to fix this really really correctly, please use PRIu32 from inttypes.h instead.
I wouldn't.
The PRI macros are required for integer types wider than signed /
unsigned int.
Narrower types promote to int or unsigned.
For equally wide types, it doesn't matter.
WARNING: multiple messages have this Message-ID (diff)
From: Markus Armbruster <armbru@redhat.com>
To: Thomas Huth <thuth@redhat.com>
Cc: AlexChen <alex.chen@huawei.com>,
lvivier@redhat.com, QEMU Trivial <qemu-trivial@nongnu.org>,
QEMU <qemu-devel@nongnu.org>, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH] qtest: Fix bad printf format specifiers
Date: Thu, 05 Nov 2020 09:19:58 +0100 [thread overview]
Message-ID: <877dr0rz9t.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <67eca43e-99ea-f2ce-5d9e-a9cb5c7a3a83@redhat.com> (Thomas Huth's message of "Wed, 4 Nov 2020 11:44:46 +0100")
Thomas Huth <thuth@redhat.com> writes:
> On 04/11/2020 11.23, AlexChen wrote:
>> We should use printf format specifier "%u" instead of "%d" for
>> argument of type "unsigned int".
>>
>> Reported-by: Euler Robot <euler.robot@huawei.com>
>> Signed-off-by: Alex Chen <alex.chen@huawei.com>
>> ---
>> tests/qtest/arm-cpu-features.c | 8 ++++----
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/tests/qtest/arm-cpu-features.c b/tests/qtest/arm-cpu-features.c
>> index d20094d5a7..bc681a95d5 100644
>> --- a/tests/qtest/arm-cpu-features.c
>> +++ b/tests/qtest/arm-cpu-features.c
>> @@ -536,7 +536,7 @@ static void test_query_cpu_model_expansion_kvm(const void *data)
>> if (kvm_supports_sve) {
>> g_assert(vls != 0);
>> max_vq = 64 - __builtin_clzll(vls);
>> - sprintf(max_name, "sve%d", max_vq * 128);
>> + sprintf(max_name, "sve%u", max_vq * 128);
>>
>> /* Enabling a supported length is of course fine. */
>> assert_sve_vls(qts, "host", vls, "{ %s: true }", max_name);
>> @@ -556,7 +556,7 @@ static void test_query_cpu_model_expansion_kvm(const void *data)
>> * unless all larger, supported vector lengths are also
>> * disabled.
>> */
>> - sprintf(name, "sve%d", vq * 128);
>> + sprintf(name, "sve%u", vq * 128);
>> error = g_strdup_printf("cannot disable %s", name);
>> assert_error(qts, "host", error,
>> "{ %s: true, %s: false }",
>> @@ -569,7 +569,7 @@ static void test_query_cpu_model_expansion_kvm(const void *data)
>> * we need at least one vector length enabled.
>> */
>> vq = __builtin_ffsll(vls);
>> - sprintf(name, "sve%d", vq * 128);
>> + sprintf(name, "sve%u", vq * 128);
>> error = g_strdup_printf("cannot disable %s", name);
>> assert_error(qts, "host", error, "{ %s: false }", name);
>> g_free(error);
>> @@ -581,7 +581,7 @@ static void test_query_cpu_model_expansion_kvm(const void *data)
>> }
>> }
>> if (vq <= SVE_MAX_VQ) {
>> - sprintf(name, "sve%d", vq * 128);
>> + sprintf(name, "sve%u", vq * 128);
>> error = g_strdup_printf("cannot enable %s", name);
>> assert_error(qts, "host", error, "{ %s: true }", name);
>> g_free(error);
>>
>
> max_vq and vq are both "uint32_t" and not "unsigned int" ... so if you want
Not quite. They are, but the product isn't. Assuming it is is actually
a common misconception of how C works.
C99 § 6.3.1.8 "Usual arithmetic conversions" applies. Short summary:
first, both operands of * undergo integer promotion (§ 6.3.1.1 Boolean,
characters, and integers), then we find a "common" integer type, convert
the operands to it, and multiply in that type.
128 is int (§ 6.4.4.1 Integer constants). Integer promotion does
nothing.
@vq is uint32_t per its declaration. If int can represent any uint32_t
value, it promotes to int; else if unsigned int can represent, it
promotes to unsigned int; else it stays the same.
In QEMU practice, "stays the same" is impossible, because unsigned int
narrower than 32 bits is. "Promotes to int" is unlikely, because int
wider than 32 bits is.
So, the "common" type is almost certainly unsigned int for us, but we
may want to do the right thing for the unlikely case of signed int.
It is uint32_t only when it's unsigned int, and the system makes
uint32_t an alias for unsigned int, say with typedef unsigned uint32_t.
> to fix this really really correctly, please use PRIu32 from inttypes.h instead.
I wouldn't.
The PRI macros are required for integer types wider than signed /
unsigned int.
Narrower types promote to int or unsigned.
For equally wide types, it doesn't matter.
next prev parent reply other threads:[~2020-11-05 8:20 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-04 10:23 [PATCH] qtest: Fix bad printf format specifiers AlexChen
2020-11-04 10:23 ` AlexChen
2020-11-04 10:44 ` Thomas Huth
2020-11-04 10:44 ` Thomas Huth
2020-11-05 5:14 ` AlexChen
2020-11-05 5:14 ` AlexChen
2020-11-05 5:58 ` Thomas Huth
2020-11-05 5:58 ` Thomas Huth
2020-11-06 6:33 ` Markus Armbruster
2020-11-06 6:33 ` Markus Armbruster
2020-11-06 14:18 ` Philippe Mathieu-Daudé
2020-11-06 15:36 ` Markus Armbruster
2020-11-06 15:36 ` Markus Armbruster
2020-11-08 7:51 ` Thomas Huth
2020-11-08 7:51 ` Thomas Huth
2020-11-09 7:57 ` Markus Armbruster
2020-11-09 7:57 ` Markus Armbruster
2020-11-09 9:56 ` Alex Chen
2020-11-09 9:56 ` Alex Chen
2020-11-09 12:50 ` Markus Armbruster
2020-11-10 8:09 ` Thomas Huth
2020-11-10 8:09 ` Thomas Huth
2020-11-11 9:53 ` Markus Armbruster
2020-11-11 9:53 ` Markus Armbruster
2020-11-05 8:19 ` Markus Armbruster [this message]
2020-11-05 8:19 ` Markus Armbruster
2020-11-08 7:42 ` Thomas Huth
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=877dr0rz9t.fsf@dusky.pond.sub.org \
--to=armbru@redhat.com \
--cc=alex.chen@huawei.com \
--cc=lvivier@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-trivial@nongnu.org \
--cc=thuth@redhat.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 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.