From: Richard Guy Briggs <rgb@redhat.com>
To: Steve Grubb <sgrubb@redhat.com>
Cc: linux-audit@redhat.com, Peter Vrabec <pvrabec@redhat.com>
Subject: Re: [PATCH] errormsg: use descriptive macros for error numbers
Date: Wed, 12 Apr 2017 02:39:26 -0400 [thread overview]
Message-ID: <20170412063926.GM18559@madcap2.tricolour.ca> (raw)
In-Reply-To: <5183071.ISI9gAqKeZ@x2>
On 2017-04-11 17:33, Steve Grubb wrote:
> On Tuesday, April 4, 2017 6:36:52 AM EDT Richard Guy Briggs wrote:
> > Convert all the numerical error return codes in comparison option and field
> > option parsing routines audit_rule_interfield_comp_data() and
> > audit_rule_fieldpair_data() to descriptive macros for easier code navigation
> > and verification.
> >
> > See: https://github.com/linux-audit/audit-userspace/issues/11
> >
> > Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> > ---
> > lib/errormsg.h | 29 +++++++++++++++++++
> > lib/libaudit.c | 84
> > ++++++++++++++++++++++++++++---------------------------- 2 files changed,
> > 71 insertions(+), 42 deletions(-)
>
> Applied.
Thanks for taking this patch. Are you able to adapt your workflow so
that the original author of contributed patches shows up in the git
commit author line with the original patch timestamp? Looking back
through the repo history it appears you are the only author since you
took over from mitr, which I know not to be true. As it is now, you
appear to be the author of this patch and the patch date is a week later
than it actually was. There is no way to the original author now. "git
am" is able to do this.
> But we still have hardcoded numbers in the err_msgtab[]. :-)
Yes. Once all the return codes that use this function have been
accounted for and have been converted to macros, we can throw the macros
into an enum and not care what their actual value is and then convert
the table. One step at a time! I wasn't able to see any of the
duplication, overloading or message meanings drifting over time without
this first step.
Note: GitHub Milestones: I had arbitrarily picked the only listed
milestone in github (which seemed reasonable at the time) to see how
well that mechanism worked. Was that an appropriate milestone? Can we
create some more and start using that facility for items in your TODO?
> -Steve
- RGB
--
Richard Guy Briggs <rgb@redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
next prev parent reply other threads:[~2017-04-12 6:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-04 10:36 [PATCH] errormsg: use descriptive macros for error numbers Richard Guy Briggs
2017-04-11 21:33 ` Steve Grubb
2017-04-12 6:39 ` Richard Guy Briggs [this message]
2017-04-12 22:14 ` Steve Grubb
2017-04-13 8:42 ` Richard Guy Briggs
2017-05-17 1:32 ` Richard Guy Briggs
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170412063926.GM18559@madcap2.tricolour.ca \
--to=rgb@redhat.com \
--cc=linux-audit@redhat.com \
--cc=pvrabec@redhat.com \
--cc=sgrubb@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox