On Thu, Mar 27, 2025 at 04:49:10PM +0100, Florian Westphal wrote: > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > > On Mon, Mar 24, 2025 at 12:52:58PM +0100, Florian Westphal wrote: > > > > Don't rely on a successful evaluation of set->key. > > > > With this input, set->key fails validation but subsequent > > > > element evaluation asserts because the context points at > > > > the set key -- an empty concatenation. > > > > > > > > Causes: > > > > nft: src/evaluate.c:1681: expr_evaluate_concat: Assertion `!list_empty(&ctx->ectx.key->expressions)' failed. > > > > > > > > After patch: > > > > internal:0:0-0: Error: unqualified type specified in set definition. Try "typeof expression" instead of "type datatype". > > > > internal:0:0-0: Error: Could not parse symbolic invalid expression > > > > > > Maybe block this from the json parser itself? > > > > Maybe this instead? This covers for empty concatenation in both set > > key and set data. > > I don't like the idea of having to keep double-error-checks in > both json and bison frontends. > > I would prefer a generic solution where possible, unless > there is some other advantage such as better error reporting. I have been trying to trigger this from the bison parser, but I could not. I think assertion are still useful to denote something is very broken if we get to the evaluation step with an empty concatenation.
