Re: improvements to PF macros

________________________________
From: Vadim Goncharov <vadimnuclight@gmail.com>
Sent: October 19, 2026 5:47 PM
To: Robert Austen <robert.austen@willowglensystems.com>
Cc: current@freebsd.org <current@freebsd.org>; hackers@freebsd.org <hackers@freebsd.org>
Subject: Re: improvements to PF macros

[You don't often get email from vadimnuclight@gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

On Thu, 8 Oct 2026 21:00:33 +0000
Robert Austen <robert.austen@willowglensystems.com> wrote:

> I've been working with PF under freebsd for a few months, and have noticed a
> recurring theme in the forums, that the macros in PF could be improved.
>
> I notice that it is often difficult to define one macro in terms of
> another, and just addressing that item alone would help write cleaner
> simpler rules.

I'm not using pf, just soming from Lex/Yacc side, because changing syntax
can establish a precedent for "downstream" projects: at $job I am doing custom
firewall-like thing, with some syntax parts borrowed from FreeBSD firewalls,
and I think I am not the only where "@" is already got used for other things.
What about, say, "$$" ?

because '$' is used in the yylex part of the pfctl parser, it's probably the more difficult
operator to use. Certainly requires a lot more code. One could use a token in the
form of a string, eg. VAR and do it that way.

I don't believe I've seen anything that uses '@'.  Historically the '@' was used
in assembler to retrieve what a pointer points at, so it seemed a good fit.
Besides., the '@' only appears in the varstring and numberstring grammars,
and no where else, so it's only meant to allow macros to be manipulated
in a basic way.

Do you have an example where '@' is being used inside of the pf.conf syntax?
I don't see any.


[...]
> this change allows a macro to be defined in terms of an existing macro,
> using the '@' to refer to that existing macro by name, rather than expanding
> the macro out and causing the eventual 'syntax error' response that often
> results.
>
> this allows using one macro within another
> set_ext_tag = "tag \"from_outside\""
> is_int_tag = "tagged \"from_inside\""
>
> combined_tags = @set_ext_tag @is_int_tag
>
> this results in $combined_tags expanding to:
>                                   tag "from_outside" tagged "from_inside"

I do not understand this example - man page close to beginning shows:

           ext_if = "kue0"
           all_ifs = "{" $ext_if lo0 "}"
           pass out on $ext_if from any to any

what your example achieves what's not covered already?


Not at all.
Try making a macro from an existing macro that has a tag, or label.
The quotes are very difficult to requote, because of the way the $macro
is expanded by the yylex. Rather than totally changing the macro expansion,
looking up the macro from the symget function and using that value
(rather than expanding the macro and having to reparse it) makes for a
simple way to define macros in terms of other macros.

The '+' allows concat things that seem easy, but don't work, like adding
a final quad to a dot quad address, such as
myIP = 192.168.0.$myValue

because the syntax requires a space
myIP = 192.168.0. $myValue

and then you get a space in the middle of your macro, which is not what anyone wants.
that's why I added the '+', to do a proper (c++) concat, without the annoying space.

> [...]
> the existing grammar for varstring inserts a space, which is not always
> helpful, so the second change. this change adds the '+' operator to
> explicitly concat two strings together (either or both could be a macro),
> which allows the following
>
> subnet = "192.168.0."
> client = @subnet + "206"
>
>
> this results in $client expanding to:
>                        192.168.0.206

This looks like an overkill for simple task - e.g. in Shell, you do not need
separate strings concatenation operator - you just concatenate them, e.g.
inside quotes. So your real problem seems to be the statement

  Macros are not expanded inside quotes.

from manpage. This can't be changed literally without breaking backwards
compatibility, but `man sh` can serve as inspiration, and may be `man make`,
too. For example, what about syntax like $'' inside which macros are expanded?
Or $() in make-style? Can this actuallt solve BOTH of your problems?..


exactly, that's why I propose these two simple changes to the macro definition
grammar (and only to those), rather than breaking everything.

Robert


--
WBR, @nuclight