When building with Clang we encounter this warning:
| net/ipv4/esp4.c:1114:5: error: format specifies type 'unsigned short'
| but the argument has type 'int' [-Werror,-Wformat]
| aalg_desc->uinfo.auth.icv_fullbits / 8);
`aalg_desc->uinfo.auth.icv_fullbits` is a u16 but due to default
argument promotion becomes an int.
Variadic functions (printf-like) undergo default argument promotion.
Documentation/core-api/printk-formats.rst specifically recommends using
the promoted-to-type's format flag.
As per C11 6.3.1.1:
(https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf) `If an int
can represent all values of the original type ..., the value is
converted to an int; otherwise, it is converted to an unsigned int.
These are called the integer promotions.` Thus it makes sense to change
%hu to %d not only to follow this standard but to suppress the warning
as well.
Nathan also mentions: This solution is in line with printk-formats.rst
after commit cbacb5ab0aa0 ("docs: printk-formats: Stop encouraging use
of unnecessary %h[xudi] and %hh[xudi]").
Link: https://github.com/ClangBuiltLinux/linux/issues/378
Suggested-by: Nathan Chancellor <[email protected]>
Signed-off-by: Justin Stitt <[email protected]>
---
This is the exact same issue (and fix) as:
https://lore.kernel.org/all/[email protected]/
This really should have been a 2-patch series but I've been going
through warnings and systematically fixing them whilst submitting
patches as I go.
net/ipv4/esp4.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
index b21238df3301..de48dcac18eb 100644
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -1108,7 +1108,7 @@ static int esp_init_authenc(struct xfrm_state *x)
err = -EINVAL;
if (aalg_desc->uinfo.auth.icv_fullbits / 8 !=
crypto_aead_authsize(aead)) {
- pr_info("ESP: %s digestsize %u != %hu\n",
+ pr_info("ESP: %s digestsize %u != %d\n",
x->aalg->alg_name,
crypto_aead_authsize(aead),
aalg_desc->uinfo.auth.icv_fullbits / 8);
--
2.37.0.rc0.161.g10f37bed90-goog
On Thu, Jul 7, 2022 at 11:15 AM Justin Stitt <[email protected]> wrote:
>
> This is the exact same issue (and fix) as:
> https://lore.kernel.org/all/[email protected]/
>
> This really should have been a 2-patch series but I've been going
> through warnings and systematically fixing them whilst submitting
> patches as I go.
In that case, since Joe had feedback on that patch, perhaps you can
fold this into that patch, and apply Joe's suggestions (sending a v2)?
--
Thanks,
~Nick Desaulniers