[illumos-Developer] webrev: 374 cron should send more useful mail

[Joshua M. Clulow]

On Wed, Oct 27, 2010 at 1:46 AM, Garrett D'Amore <garrett at nexenta.com> wrote:
> On Tue, 2010-10-26 at 17:20 +1100, Joshua M. Clulow wrote:
>> On Tue, Oct 26, 2010 at 4:45 PM, Garrett D'Amore <garrett at nexenta.com> wrote:
>> crontab appears relatively inconsistent in this respect.  I can
>> certainly use gettext() -- should I also be fixing other #defined
>> messages that don't use gettext() at the same time?
> Its not a bad idea.  Perhaps file a bug on the issue?

I've sprinkled some gettext() into crontab.c ...

>> Yes, I should!  There are a number of other places that don't have
>> proper void casts -- in particular directly above my addition where I
>> copied most of the boilerplate from in order to be consistent with the
>> existing code.  Should I fix those too?
> Yes please.  Have a try at making this code pass lint too... I'm
> assuming it isn't currently linted, but since you're here anyway....

... and I've cut down the output of "dmake lint" from:
   http://pastie.org/1294603

to only:

----------------
"att2.l", line 43: warning: declaration unused in block: yyprevious
(E_BLOCK_DECL_UNUSED)
"att2.l", line 825: warning: assignment operator "=" found where "=="
was expected (E_EQUALITY_NOT_ASSIGNMENT)
"atrm.c", line 109: warning: expression, or sub-expression, has null
effect (E_EXPR_NULL_EFFECT)
"/ws/illumos-cron/usr/src/cmd/cron/att2.l", line 744: warning:
function returns value which is sometimes ignored: fprintf
(E_FUNC_RET_MAYBE_IGNORED2)
----------------

I have updated the webrev to include the changes here:
   http://cr.illumos.org/view/cb57coq2/webrev-374d-cron-subject/

There are a couple of changes in particular that I think require
discussion as they change the behaviour of crontab/at somewhat.  Lint
had highlighted the fact that nothing was being done with the return
codes of the audit_{crontab,at}* functions.  Though my understanding
could be flawed I had expected that if the auditing subsystem couldn't
write a record for an operation like "modify a crontab" or "delete an
at entry" then the actual modification or deletion should not be
allowed to continue lest there be a hole in the audit trail.  This
seems to be the way the audit event for *creating* an at job is
already handled so I've brought the modify/delete audit events into
line.

The rest of the changes shouldn't affect existing functionality.

Feedback appreciated -- particularly on:
  * Is there a better way to prevent the "multiple definition" of
main() in the various C files from being flagged as a warning by lint?
  * Where are the line numbers for the lint warnings on the lex files
coming from?  They don't appear to match up with anything useful.

Cheers.

-- 
Joshua M. Clulow
UNIX Admin/Developer
http://blog.sysmgr.org