* [PATCH 1/2] lib/cryptodev: avoid implicit conversion to 64 bit number
@ 2024-11-28 1:53 Andre Muezerie
2024-11-28 1:53 ` [PATCH 2/2] lib/hash: " Andre Muezerie
0 siblings, 1 reply; 2+ messages in thread
From: Andre Muezerie @ 2024-11-28 1:53 UTC (permalink / raw)
To: Akhil Goyal, Fan Zhang; +Cc: dev, Andre Muezerie
MSVC issues the warning below:
../lib/cryptodev/rte_cryptodev.c(623): warning C4334: '<<':
result of 32-bit shift implicitly converted to 64 bits
(was 64-bit shift intended?)
The code would be better off by using 64 bit numbers to begin with.
That eliminates the need for a conversion to 64 bits later.
Signed-off-by: Andre Muezerie <andremue@linux.microsoft.com>
---
lib/cryptodev/rte_cryptodev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c
index 85a4b46ac9..a49b0662f3 100644
--- a/lib/cryptodev/rte_cryptodev.c
+++ b/lib/cryptodev/rte_cryptodev.c
@@ -620,7 +620,7 @@ rte_cryptodev_asym_xform_capability_check_hash(
{
bool ret = false;
- if (capability->hash_algos & (1 << hash))
+ if (capability->hash_algos & RTE_BIT64(hash))
ret = true;
rte_cryptodev_trace_asym_xform_capability_check_hash(
--
2.47.0.vfs.0.3
^ permalink raw reply [flat|nested] 2+ messages in thread
* [PATCH 2/2] lib/hash: avoid implicit conversion to 64 bit number
2024-11-28 1:53 [PATCH 1/2] lib/cryptodev: avoid implicit conversion to 64 bit number Andre Muezerie
@ 2024-11-28 1:53 ` Andre Muezerie
0 siblings, 0 replies; 2+ messages in thread
From: Andre Muezerie @ 2024-11-28 1:53 UTC (permalink / raw)
To: Yipeng Wang, Sameh Gobriel, Bruce Richardson, Vladimir Medvedkin
Cc: dev, Andre Muezerie
MSVC issues the warnings below:
1) ../lib/hash/rte_thash_gf2_poly_math.c(128): warning C4334: '<<':
result of 32-bit shift implicitly converted to 64 bits
(was 64-bit shift intended?)
The code would be better off by using 64 bit numbers to begin with.
That eliminates the need for a conversion to 64 bits later.
2) ../lib/hash/rte_thash.c(568): warning C4334: '<<':
result of 32-bit shift implicitly converted to 64 bits
(was 64-bit shift intended?)
1ULL should be used as the result of the bit shift gets multiplied
by sizeof(uint32_t).
Signed-off-by: Andre Muezerie <andremue@linux.microsoft.com>
---
lib/hash/rte_thash.c | 2 +-
lib/hash/rte_thash_gf2_poly_math.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/lib/hash/rte_thash.c b/lib/hash/rte_thash.c
index fa78787143..f076311b57 100644
--- a/lib/hash/rte_thash.c
+++ b/lib/hash/rte_thash.c
@@ -565,7 +565,7 @@ rte_thash_add_helper(struct rte_thash_ctx *ctx, const char *name, uint32_t len,
offset;
ent = rte_zmalloc(NULL, sizeof(struct rte_thash_subtuple_helper) +
- sizeof(uint32_t) * (1 << ctx->reta_sz_log),
+ sizeof(uint32_t) * (1ULL << ctx->reta_sz_log),
RTE_CACHE_LINE_SIZE);
if (ent == NULL)
return -ENOMEM;
diff --git a/lib/hash/rte_thash_gf2_poly_math.c b/lib/hash/rte_thash_gf2_poly_math.c
index 825da4382f..858884b4d4 100644
--- a/lib/hash/rte_thash_gf2_poly_math.c
+++ b/lib/hash/rte_thash_gf2_poly_math.c
@@ -119,16 +119,16 @@ static uint32_t
gf2_mul(uint32_t a, uint32_t b, uint32_t r, int degree)
{
uint64_t product = 0;
- uint64_t r_poly = r|(1ULL << degree);
+ uint64_t r_poly = r | RTE_BIT64(degree);
for (; b; b &= (b - 1))
product ^= (uint64_t)a << (rte_bsf32(b));
for (int i = degree * 2 - 1; i >= degree; i--)
- if (product & (1 << i))
+ if (product & RTE_BIT64(i))
product ^= r_poly << (i - degree);
- return product;
+ return (uint32_t)product;
}
static uint32_t
--
2.47.0.vfs.0.3
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2024-11-28 1:54 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-11-28 1:53 [PATCH 1/2] lib/cryptodev: avoid implicit conversion to 64 bit number Andre Muezerie
2024-11-28 1:53 ` [PATCH 2/2] lib/hash: " Andre Muezerie
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).