[PATCH v2 03/10] test-pmd: fix printf format string mismatch
Andre Muezerie
andremue at linux.microsoft.com
Wed Feb 19 18:08:12 CET 2025
On Tue, Feb 18, 2025 at 05:07:03PM +0000, Bruce Richardson wrote:
> 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:
> > > On Tue, Feb 18, 2025 at 08:32:02AM -0800, Andre Muezerie wrote:
> > > > 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 <andremue at linux.microsoft.com>
> > > > Signed-off-by: Chengwen Feng <fengchengwen at huawei.com>
> > > > ---
> > > > 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
Yes, I'll do that.
More information about the dev
mailing list