On Tue, Feb 18, 2025 at 09:03:01AM -0800, Andre Muezerie wrote:

On Tue, Feb 18, 2025 at 04:46:56PM +0000, Bruce Richardson wrote:

quoted

On Tue, Feb 18, 2025 at 08:32:02AM -0800, Andre Muezerie wrote:

quoted

Compiling with MSVC results in warnings like the one below:

app/test-pmd/csumonly.c(1085): warning C4477: 'printf' : format string
    '%d' requires an argument of type 'int',
    but variadic argument 1 has type 'uint64_t'

Signed-off-by: Andre Muezerie <redacted>
Signed-off-by: Chengwen Feng <redacted>
---
 app/test-pmd/csumonly.c | 23 ++++++++++++-----------
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index d77a140641..8de5ad6ad9 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c

@@ -1070,7 +1070,7 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
 				info.l2_len, rte_be_to_cpu_16(info.ethertype),
 				info.l3_len, info.l4_proto, info.l4_len, buf);
 			if (rx_ol_flags & RTE_MBUF_F_RX_LRO)
-				printf("rx: m->lro_segsz=%u\n", m->tso_segsz);
+				printf("rx: m->lro_segsz=%" PRIu64 "\n", (uint64_t)m->tso_segsz);

tso_segsz is already uint64_t, so no need for the cast.

The compilers differ in behavior here. tso_segsz only uses 16 bits of the uint64_t,
and gcc tries to be smart about it and implicitly converts tso_segsz into an int
(since it fits into an int). Msvc does not do that, and keeps the type for tso_segsz
as uint64_t. To support both compilers it seems there's no way to avoid the cast.

Ok. Then can we just keep the %u and cast to either unsigned or uint16_t?
No need to update the format char if we are casting, right?

/Bruce