On Tue, Aug 20, 2013 at 09:55:16AM -0700, Steve Beattie wrote:
> 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).I like this, maybe we can ask John to include this in his huge pile of cleanup patches. Thanks for pointing out the clean solution. :) > (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.) I thought about suggesting this but figured I'd forget about the aliasing in the future. :) Thanks
signature.asc
Description: Digital signature
-- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
