[resurrecting an old thread, sorry]
On Thu, Aug 08, 2013 at 06:17:08PM -0700, Seth Arnold wrote:
> On Thu, Aug 01, 2013 at 12:31:30AM -0700, Tyler Hicks wrote:
> > @@ -233,9 +261,14 @@ key: TOK_KEY_OPERATION TOK_EQUALS TOK_QUOTED_STRING
> > { ret_record->magic_token = $3;}
> > | TOK_KEY_INFO TOK_EQUALS TOK_QUOTED_STRING
> > { ret_record->info = $3;}
> > + | TOK_KEY_PEER_INFO TOK_EQUALS TOK_QUOTED_STRING
> > + { ret_record->peer_info = $3;}
> > | key_pid
> > + | key_peer_pid
> > | TOK_KEY_PROFILE TOK_EQUALS safe_string
> > { ret_record->profile = $3;}
>
> Hrm, how does a 'key_pid' or 'key_peer_pid' match, in a way that there's
> a $3 to assign from?
The action 'ret_record->profile = $3;' is not applied to key_pid or
key_peer_pid, only the 'TOK_KEY_PROFILE TOK_EQUALS safe_string' rule,
that's why.
On Thu, Aug 08, 2013 at 11:39:01PM -0700, Seth Arnold wrote:
> On Thu, Aug 08, 2013 at 10:22:11PM -0700, Tyler Hicks wrote:
> > > > > + { /* Free existing arrays because exe= and comm= maps to the
> > > > > same
> > > > > + aa_log_record member */
> > > > > + free(ret_record->comm);
> > > > > + ret_record->comm = $3;
> > > > > + }
> > > > > | TOK_KEY_COMM TOK_EQUALS safe_string
> > > > > - { ret_record->comm = $3;}
> > > > > + { /* Free existing arrays because exe= and comm= maps to the
> > > > > same
> > > > > + aa_log_record member */
> > > > > + free(ret_record->comm);
> > > > > + ret_record->comm = $3;
> > > > > + }
> > > >
> > > > The actions for TOK_KEY_COMM and TOK_KEY_EXE are the same, we could
> > > > combine them into one action block.
>
> > Oops... Seth and I chatted this over in IRC and concluded that we can't
> > combine these two actions. So, I've reverted this change.
>
> So, here's my mistake. _Flex_ supports sharing actions via |:
>
> The first three rules share the fourth's action since they use the
> special ‘|’ action.
>
> http://flex.sourceforge.net/manual/Actions.html
>
> _Bison_ also uses | for "further matches for this rule", but the actions
> aren't shared:
>
> If you don't specify an action for a rule, Bison supplies a default:
> $$ = $1. Thus, the value of the first symbol in the rule becomes the
> value of the whole rule.
>
> http://www.gnu.org/software/bison/manual/bison.html#Actions
Correct. However, that doesn't mean that the identical actions for
the two different rules couldn't be unified. The way to do it in
bison would be to add a subrule that matches either TOK_KEY_COMM and
TOK_KEY_EXE and use that subrule as the first entry in the rules that
we wish to coalesce the actions; e.g.:
| exe_tokens TOK_EQUALS safe_string
{ /* Free existing arrays because exe= and comm= maps to the same
aa_log_record member */
free(ret_record->comm);
ret_record->comm = $3;
}
exe_tokens: TOK_KEY_COMM | TOK_KEY_EXE
Whatever gets returned as $$ for exe_tokens will be considered as $1
in the 'exe_tokens TOK_EQUALS safe_string' rule (though in this case
the code doesn't actually care what the value of $1 is).
(You could alternatively just have the lexer return the same taken for
for 'comm' and 'exe'. Which probably wouldn't be bad, unless we ever
decided at a later point that we wanted to treat them separately.)
--
Steve Beattie
<[email protected]>
http://NxNW.org/~steve/
signature.asc
Description: Digital signature
-- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
