________________________________ From: Vadim Goncharov <[email protected]> Sent: October 19, 2026 5:47 PM To: Robert Austen <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Re: improvements to PF macros
[You don't often get email from [email protected]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] On Thu, 8 Oct 2026 21:00:33 +0000 Robert Austen <[email protected]> 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
