Re: more consistently use "st" as the name for struct pf_state variables

2023-01-05 Thread Alexandr Nedvedicky
On Thu, Jan 05, 2023 at 08:32:44PM +1000, David Gwynne wrote: > > > > On 5 Jan 2023, at 18:56, Alexandr Nedvedicky wrote: > > > > Hello, > > > > On Wed, Jan 04, 2023 at 09:36:38PM +1000, David Gwynne wrote: > >> and "stp" for pf_state ** variables. > >> > >I agree with established naming

Re: more consistently use "st" as the name for struct pf_state variables

2023-01-05 Thread David Gwynne
> On 5 Jan 2023, at 18:56, Alexandr Nedvedicky wrote: > > Hello, > > On Wed, Jan 04, 2023 at 09:36:38PM +1000, David Gwynne wrote: >> and "stp" for pf_state ** variables. >> >I agree with established naming conventions. > >I'm also fine with keeping some exceptions such as `a` and

Re: more consistently use "st" as the name for struct pf_state variables

2023-01-05 Thread Alexandr Nedvedicky
Hello, On Wed, Jan 04, 2023 at 09:36:38PM +1000, David Gwynne wrote: > and "stp" for pf_state ** variables. > I agree with established naming conventions. I'm also fine with keeping some exceptions such as `a` and `b` in pf_state_compare_id(), local variables `tail`, `head` in

more consistently use "st" as the name for struct pf_state variables

2023-01-04 Thread David Gwynne
and "stp" for pf_state ** variables. there should be no functional change here. ok? Index: pf.c === RCS file: /cvs/src/sys/net/pf.c,v retrieving revision 1.1167 diff -u -p -r1.1167 pf.c --- pf.c4 Jan 2023 10:31:55 -