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