Re: CVS commit: src/usr.sbin/arp

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        15 Aug 2003 12:27:28 -0400
    From:        "Perry E. Metzger" <perry%piermont.com@localhost>
    Message-ID:  <87wudeyjgv.fsf%snark.piermont.com@localhost>

  | "It depends" -- there are instances in which you're using automated
  | tools to assure that you don't have memory leaks and it is easier to
  | detect the real ones if you just free everything you allocate.

Yes, in the earlier message of mine in this thread I mentioned that case,
and I agree, if you have a program for which memory leaks are a possibility,
and need tracking down, then it makes life easier to free everything
possible, so the final accounting of unfreed memory is easier to reconcile
(I've never seen a case where it has been possible to free everything in
a program where it makes any sense to use one of those tools - but the
closer it is possible to come the better).

But almost by definition, a program that runs, does something, and exits,
cannot have memory leaks, so it makes no sense to even contemplate wasting
time using one of those tools on one, hence it also makes no sense to
race around adding useless code, whether the rationale would be to pacify
a tool you're not going to use, or just with some fanatic ideal of
tidyness.

kre