Re: [PATCH v2 nft] parser: tcpopt: fix tcp option parsing with NUM + length field

[Thomas Haller <thaller@redhat.com>]

On Wed, 2023-12-06 at 14:24 +0100, Florian Westphal wrote:
> Thomas Haller <thaller@redhat.com> wrote:
> > > "metainfo": {
> > > -        "json_schema_version": 1,
> > > +        "version": "VERSION",
> > > "release_name": "RELEASE_NAME",
> > > -        "version": "VERSION"
> > > +        "json_schema_version": 1
> > > }
> > > },
> > > 
> > > i.e. it fails validation because the on-record file has a
> > > different
> > > layout/ordering than what is expected.
> > 
> > Does this mean all tests on `master` have this problem?
> 
> No, those are all raw binary-like oneline dumps.

sorry, I don't follow.

The patch takes the "raw binary-like oneline dump", and prettifies it.
It does so via `json-pretty.sh` script. That script, does of course not
mess up the order of dictionary keys.


> 
> > > But if you feed it into nft, nft list ruleset will generate the
> > > expected
> > > (non-json) output.
> > 
> > where do you encounter that? How to reproduce this?
> > 
> > Is this an old libjansson? Since 2.8 (2016), JSON_PRESERVE_ORDER is
> > implied. Maybe libnftables needs to set JSON_PRESERVE_ORDER flag at
> > a
> > few places.
> 
> Just format any existing json dump file with a different formatting
> tool, e.g. json_pp.

The patch has a way for prettifying JSON (json-pretty.sh). Sure, it
could also use json_pp instead, but what problem would that solve?


Thomas