[BusyBox] Re: ifconfig: Clean up. [PATCH]

[Shaun Jackman]

On 7/26/05, Rainer Weikusat <rainer.weikusat at sncag.com> wrote:
> A tool that detects a non-existant ressource leak is broken and should
> be fixed. No, the fact that MSVC++ is such a tool, too, is not an
> excuse.

Non-existent? Hardly. The resource -- a file descriptor, in this case
-- was allocated. It wasn't deallocated. Granted it's not a continuous
leak, but is a leak nonetheless. I can't comment on MSVC++, never used
it myself.
 
> > I'll mention that in my case -- even though as far as I know no one
> > else is using this -- I'm using a forkless busybox that imitates
> > fork/exit using setjmp/longjmp. The upside is that fork is never
> > called (woot!); the downside is that you don't get automatic resource
> > deallocation by program exit for free.
> 
> OIC: Basically, you are using a broken emulation layer and instead of
> fixing that, you'd like to have the code everyone else uses account
> for the bugs in your broken emulation layer. Why don't you just walk
> the descriptor table in exit and close everything that's still open?
> That will work reliably will all current and future busybox applets
> and required code changes in only one place?

The fok/exit macros are not broken; they are simply limited by what
can be accomplished in user space. I cannot walk the descriptor table
because in user space busybox does not have access to the kernel
internals. fork(2) is a very heavy weight system call; there are a
number of reasons why you might want to avoid it if possible. It is
possible, and in fact not even that difficult, to build a busybox
binary that does not require either fork(2) or execve(2). This opens
up busybox to a number of embedded kernels that provide file system
calls but not process calls.

Cheers,
Shaun