Re: [PATCH nft] evaluate: reject negative values for unsigned datatypes

[Avinash Duduskar <avinash.duduskar@gmail.com>]

On Thu, Aug 13, 2026 at 02:58:41PM +0200, Pablo Neira Ayuso wrote:
> Yes, I wonder if we can do this in a more generic way, like specifying
> in the datatype itself the min and maximum value expected from the
> integer.

Turns out the special case should not exist at all: it is dead code, so
neither the flag bit nor a validate callback would have a user here.

A negative priority never arrives at this check as a negative mpz. Bare
and json numeric priorities are built as raw C ints by both frontends,
priority_type_parse() throws away integer_type_parse()'s result and
rebuilds symbols from atoi(), and the name-plus-offset forms are
computed as C ints in evaluate_priority(). Instrumenting the top of
expr_evaluate_integer() agrees:

  priority -300 (text)  dtype=priority  sgn=1   val=4294966996
  prio: -300    (json)  dtype=priority  sgn=1   val=4294966996
  element "-1"          dtype=mark      sgn=-1  val=-1

On min/max: both bounds this function enforces today come from the eval
context (ectx.maxval from numgen/hash, the mask from ectx.len), not from
the datatype, so a validate hook would sit beside them with no in-tree
user.

Dropping the special case also covers a third spelling of the bug found
while testing: "elem": [-1] as a json number is accepted today and
stored as element 1, like the string forms. The plain check rejects it
too.

v2 follows with the unconditional check and test arms for all three
forms plus flowtable priority. If the validate interface is wanted for
other reasons, I would do it as a separate patch on top.

Thanks,
Avinash