DragonFly BSD
DragonFly commits List (threaded) for 2005-03
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: cvs commit: src/usr.bin/mkfifo mkfifo.c


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Wed, 2 Mar 2005 14:13:24 -0800 (PST)

:...
:> There's one reason: setting a good example.  If someone, say, copies
:> this code into an unbounded loop in their own program, they'll leak
:> memory if they don't free modep.  Not that programmers should blindly
:> copy example code without reading the appropriate manual pages, every
:> little bit helps.
:
:I actually agree here. I would much prefere to see free(). Also, wouldnt
:exit() use the cycles that free() would anyway?
:
:If this view is taken, I can show you 'MUCH' more code that does exactly
:this. (Example: ln). This is why I thought it was the accepted practice.
:
:> 
:> And considering it's only one structure being freed (and not, say, a
:> complicated cyclic graph-like structure), the waste of cycles involved
:> in freeing it is pretty minor.
:> 
:> Just my 2c.
:> 
:> -Chris
:
:-- 
:			- Liam J. Foy
:			<liamfoy@xxxxxxxxxxxxx>

    A library API call that allocates temporary storage should certainly 
    free() it, as well as any other compartmentalized piece of code.  But
    the case here is not a compartmentalized piece of code, it's just the
    entire application exit()ing.  You do not have to free() junk just
    before you are about to call exit().

    And, no exit() will not use any additional cycles because you didn't
    free() up some memory.  The OS just blasts the pages to oblivion.  
    free() does not actually destroy the underlying pages, at least not
    for small allocations.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]