Re: [PATCH v2 2/2] net: macb: fix format-truncation warning

[Sean Chang]

On Tue, Feb 17, 2026 at 2:35 AM Andrew Lunn <andrew@xxxxxxx> wrote:
> > diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
> > index 43cd013bb70e..26f9ccadd9f6 100644
> > --- a/drivers/net/ethernet/cadence/macb_main.c
> > +++ b/drivers/net/ethernet/cadence/macb_main.c
> > @@ -3159,8 +3159,8 @@ static void gem_get_ethtool_strings(struct net_device *dev, u32 sset, u8 *p)
> >
> >               for (q = 0, queue = bp->queues; q < bp->num_queues; ++q, ++queue) {
> >                       for (i = 0; i < QUEUE_STATS_LEN; i++, p += ETH_GSTRING_LEN) {
> > -                             snprintf(stat_string, ETH_GSTRING_LEN, "q%d_%s",
> > -                                             q, queue_statistics[i].stat_string);
> > +                             snprintf(stat_string, ETH_GSTRING_LEN, "q%u_%.19s",
> > +                                      q, queue_statistics[i].stat_string);
>
> These strings are special, in that they are fixed length, 32 bytes
> long, and not \0 terminated. There are some helpers at the end of
> linux/ethtool.h for dealing with these strings. You might want to use
> them.
>

Yes, I've switched to ethtool_sprintf() from linux/ethtool.h and
removed the manual
snprintf() and memcpy() calls. After testing, it behaves exactly as expected,
so I will send out [PATCH V3] shortly.

> I also wounder, why is just one architecture complaining about this?

Regarding the architecture-specific nature of the warning: I have verified that
this warning is not triggered on x86_64, even with W=1. It appears to
be specific
to the RISC-V toolchain's diagnostic analysis.

Regardless, converting to ethtool_sprintf() is the correct approach
which does not throw
any warning on the both platforms.

Best regards,
Sean