<html>
<head>
<base href="https://bugzilla.netfilter.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - __netlink_gen_concat_key assertion raised by expanding set-defining variable as a component of a set key"
href="https://bugzilla.netfilter.org/show_bug.cgi?id=1715#c5">Comment # 5</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - __netlink_gen_concat_key assertion raised by expanding set-defining variable as a component of a set key"
href="https://bugzilla.netfilter.org/show_bug.cgi?id=1715">bug 1715</a>
from <span class="vcard"><a class="email" href="mailto:kfm@plushkava.net" title="kfm@plushkava.net">kfm@plushkava.net</a>
</span></b>
<pre>(In reply to Phil Sutter from <a href="show_bug.cgi?id=1715#c3">comment #3</a>)
<span class="quote">> Just for the record: This is neither a crash nor "dying to a signal". It's
> merely an assert() call triggering because the parser constructed something
> the remaining code can't handle. Effectively this is a case of missing error
> handling (or insufficient parser strictness), not a bug.</span >
Firstly, my ability to write and work with C is rather modest, so my
terminology might not be strictly correct. Still, if I run something in the
shell and see "Aborted (core dumped)" and can also see that the value of $? is
134, it hardly seems inaccurate to say that the process did, in fact, die as a
consequence of SIGABRT (134 - 126 being 6). Clearly, nft did not get the
opportunity to formally exit. So, if it did not die as a consequence of the
ABRT signal, how would you describe what happened?
I understand that the use of assert(3) is wilful and why you would take issue
with using "crash" as a term.
I do consider this as to be a genuine bug because I do not consider assert(3)
to be an appropriate means of conveying an error to the end-user, even if it be
unintentional. I wouldn't think this to be a contentious perspective. While the
assertion served a purpose - and is better than nothing - I am certain that the
end-user would prefer to see a formal diagnostic message, with nft having the
opportunity to exit with a non-zero status value. As such, I always report
assertions caused by the parser wherever I encounter them. I have reason to
believe that such reports are welcome as prior reports in this vein have been
attended to, for which I am grateful.
<span class="quote">>
> I guess the given ruleset works if you pull the second concat part into the
> defined variable like so:
>
> define ext_if = { "eth0" . 22, "eth1" . 22 }
> [...]
> iifname .tcp dport $ext_if accept
> [...]
>
> right?</span >
Yes, it does.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are watching all bug changes.</li>
</ul>
</body>
</html>