Re: [libnftnl RFC] data_reg: Improve data reg value printing

[Phil Sutter <phil@nwl.cc>]

On Tue, Sep 16, 2025 at 02:08:03PM +0200, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > Hi Phil,
> > 
> > On Thu, Sep 11, 2025 at 04:11:45PM +0200, Phil Sutter wrote:
> > > The old code printing each field with data as u32 value is problematic
> > > in two ways:
> > > 
> > > A) Field values are printed in host byte order which may not be correct
> > >    and output for identical data will divert between machines of
> > >    different Endianness.
> > > 
> > > B) The actual data length is not clearly readable from given output.
> > > 
> > > This patch won't entirely fix for (A) given that data may be in host
> > > byte order but it solves for the common case of matching against packet
> > > data.
> > > 
> > > Fixing for (B) is crucial to see what's happening beneath the bonnet.
> > > The new output will show exactly what is used e.g. by a cmp expression.
> > 
> > Could you fix this from libnftables? ie. add print functions that have
> > access to the byteorder, so print can do accordingly.
> 
> FWIW I prefer this patch.
> 
> While it would be possible to move all printing to libnftables (and
> as you point out it has more information available wrt. to the data
> types involved, esp. byteorder), I think that printing the data
> byte-wise rather than per u32 word is sufficient for debugging a wide
> range of bugs.  In particular it will expose the true size of the
> immediate/rhs value.

Can we treat the register length fix separate from the Endian issue? I
am aware we want to reduce the amount of payload record churn, but with
this patch applied, a follow-up addressing the Endian issue should touch
only the data in host Byteorder.

Guess I'll play a bit with the suggested Byteorder fix approach to see
how straightforward it is and how much extra churn it causes.

Thanks, Phil