Re: improvements to PF macros

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, "$$" ?

[...]
> 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?

> [...]
> 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?..

-- 
WBR, @nuclight