Void values in variables (Was: Re: [PATCH] adding custom options in radv protocol, strict ipv6 regex)

[Ondrej Zajicek]

On Sat, Jun 24, 2023 at 03:13:11PM +0200, Ondrej Zajicek wrote:
> > But if I try to call "eval role()" from cli, I get an error: "runtime
> > error", and the daemon logs this:
> > 
> > bird: filters, line 2: Argument 1 of VAR_INIT must be of type int, got type void
> > 
> > So it looks like it tries to initialize it with the void value and
> > fails to do it. I haven't tracked the source of this bug.

Yes, it fails on run-time type check, as VAR_INIT instruction tries to
initialize the variable with T_VOID value. This is not an issue with
old-style variable definitions, as they are not initialized by an
bytecode instruction, they are just memset to zero (i.e. T_VOID) when a
stack frame is created during function call. I did not noticed that in
tests as all my tests use initialization to an explicit value.

Similar issue is here also with old-style variables, which are
pre-initialized with T_VOID:

  function fun() int x; int y; { x = y; return x; }

In this case both x and y are initialized to T_VOID, but then the
assignment x = y fails in VAR_SET instruction, as it expects int and
got void from y. This was (unintentionally) introduced in 2.0.8, with
improved typechecking of filters.

The example above is a toy example, but there are realistic examples
with route attributes (which are void when undefined):

  int x = bgp_med; # fails with error when bgp_med is undefined

while in older BIRD (pre 2.0.8) an equivalent of:

  int x = bgp_med;
  if defined(x) then ...

worked.


The handling of undefined value is inconsistent, and i now i remember
that we had this discussion in the past:

https://bird.network.cz/pipermail/bird-users/2018-January/011826.html

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."