cvs commit: src/usr.bin/mkfifo mkfifo.c
Liam J. Foy
liamfoy at sepulcrum.org
Wed Mar 2 14:25:49 PST 2005
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 at 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.
> Matthew Dillon
> <dillon at xxxxxxxxxxxxx>
Ok cheers, thanks for explaining. It's fixed now, sorry!
- Liam J. Foy
<liamfoy at xxxxxxxxxxxxx>
More information about the Commits