On Wednesday 10 May 2006 12:29, Klaus Weidner wrote: > > This is at the wrong level. There may be people that are writing programs > > that want any ouid. I want to stop the proliferation of field names and > > follow a convention. Forget whether or not you think people will ever > > want the information. We need a convention and then to follow it. > > Yes - but "new ouid" is also a different field name from "ouid", and > unnecessarily hard to parse,
I am writing the parser. No one else should have to worry about it. Besides, we already do this *everywhere* except in this patch. I am just trying to keep the whole thing consistent. If you see anywhere that has new_something or old_something, please let me know. In all the places I looked, the value given is considered the new value. The old value is given as old= Some examples: "audit_rate_limit=%d old=%d by auid=%u" "audit_backlog_limit=%d old=%d by auid=%u" But then there is this: audit_log_format(ab, "login pid=%d uid=%u " "old auid=%u new auid=%u", Arguably, that could be re-written as: audit_log_format(ab, "login pid=%d uid=%u " "auid=%u old auid=%u" > especially since there's currently no well defined concept of name modifiers > like "new" Its used in many places, but you are more likely to run across old. The function in the specs that was intended to do this was: const char *auparse_get_field_name_aux(auparse_state_t *au) - return supplemental information about the field's name. -Steve -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
