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: santi...@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."
