Download raw body.
bgpd: rework pt_fill and friends
On Wed, May 13, 2026 at 04:15:40PM +0200, Claudio Jeker wrote:
> pt_fill() is in some cases used by semi-trusted content (e.g. from
> bgpctl). The fatalx calls in that function are therefor a problem.
>
> This alters pt_fill to instead return a pt_entry object that can not
> exist. I decided to return a pt_entry initalised with 0xff.
> Also if the prefixlen is too big for the address family just clip it down
> to the maximum (with a log message).
>
> In pt_add(), the only place a pt_fill() object would be added to the tree,
> check if the returned object is valid. There it is ok to fatal (at least
> for now) since the code previous to pt_add() should validate the prefix.
>
> On top of this I uniformed some of the error messages and switched the
> prefixlen argument to u_int (there is no negative prefix length).
All makes sense. I assume the log_warnx("pt_fill: ...", ...) aren't
using __func__ to avoid line wraps? It would be nice if we could get
rid of the explicit function names anyway.
ok
bgpd: rework pt_fill and friends