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

["Liam J. Foy" <liamfoy@xxxxxxxxxxxxx>]

On Wed(02)/Mar/05 - , Matthew Dillon wrote:
> :...
> :> 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>


Ok cheers, thanks for explaining. It's fixed now, sorry!
-- 
			- Liam J. Foy
			<liamfoy@xxxxxxxxxxxxx>
			http://www.bsd-systems.co.uk