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 <andre...@linux.microsoft.com>
> > > > Signed-off-by: Chengwen Feng <fengcheng...@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.

Reply via email to