Hi Mitchell, Thanks for looking at this.
On Monday 03 April 2006 08:51, Mitchell Blank Jr wrote: > The gcc warning isn't correct (since audit_filter_user() only looked at > state if audit_filter_user_rules() returned non-zero, in which case 'state' > would have been initialized) However the code was needlessly complex -- > audit_filter_user_rules() carefully populated the "enum audit_state *state" > with various value but it's only caller just cares if it's AUDIT_DISABLED > or not. IIRC, this was done to mirror the filtering of syscalls. I think we discussed this last June/July. Anyways it was a long time ago. > It's shorter and simpler to just let audit_filter_user_rules() > modify its caller's return value more directly. As an added bonus this > also removes the warning. Changes to the rule matcher have to be carefully tested just in case something obscure needs it. In this case, I don't think so since its a user space originating message. > While I was looking at auditfilter.c I did some other minor cleanup > > * const-ified pointers where possible > > * both audit_data_to_entry() and audit_krule_to_data() had an unused > variable called "void *bufp" which I removed > > * [minor] I changed some variables from "int" to "unsigned int" if > they can't be negative. Since ->field_count is unsigned I think it's > a little cleaner to use an unsigned type to iterate through it These are good cleanups. In a way, I wished this was 2 patches instead of 1. I'd take all these cleanups immediately. The other one I'd probably want to put in the test kernel for a week or two just to make sure nothing relied on the state. Thanks, -Steve -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
