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

[Liam J. Foy]

On Wed(02)/Mar/05 - , Chris Pressey wrote:
> On Wed, 2 Mar 2005 11:07:06 -0800 (PST)
> Matthew Dillon <dillon at xxxxxxxxxxxxxxxxxxxx> wrote:
> 
> > 
> > :
> > :liamfoy     2005/03/02 09:32:06 PST
> > :
> > :DragonFly src repository
> > :
> > :  Modified files:
> > :    usr.bin/mkfifo       mkfifo.c 
> > :  Log:
> > :  - Make sure we free() 'modep' after setmode()
> > :  - Add stdlib.h for both free() and exit()
> > :  
> > :  Revision  Changes    Path
> > :  1.5       +3 -1      src/usr.bin/mkfifo/mkfifo.c
> > :
> > :
> > :http://www.dragonflybsd.org/cvsweb/src/usr.bin/mkfifo/mkfifo.c.diff?
> > r1=1.4&r2=1.5&f=u
> > 
> >     It's about to exit, there's no reason to free(modep), it just
> >     wastes cycles unnecessarily.
> 
> 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>
			http://www.bsd-systems.co.uk