On Wed, May 13, 2026 at 04:37:52PM +0200, Theo Buehler wrote:
> 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
 
I will look into the log_warnx again. You are right, I did not touch them
because of the line length. I will do another run over this file at some
point.

-- 
:wq Claudio