[PATCH] ls: clean up

[Vladimir N. Oleynik]

Shaun,

>> also, found memory leak one again:
>> showdirs() must call dfree(subdnp, nfiles) always,
>> not if CONFIG_FEATURE_LS_RECURSIVE only.

> I guess the thinking was probably that if ls isn't recursive, there's
> no need to clean up memory explicitly, since ls will be exiting soon
> enough. Even without recursive listing, if the argument list were long
> enough and each argument was a directory, it might be possible to
> exhaust memory.
> Comments anyone?

1$ ls dir1 dir2

dir1:
file1
dir3/

dir2:
file4
dir5/

2$ ls -R dir1

dir1:
file1
dir3/

dir1/dir3:
...

The first point call list_dir() also and must free.
The second point call and showdir() recursive too.

>> But I do not support ENABLE_FEATURE_CLEAN_UP ;-)
> 
> 
> FEATURE_CLEAN_UP has its purpose. It's very useful with dmalloc to
> ensure the system is leak-free, and as a nice side effect its useful
> to support a system where busybox isn't forking and exiting with every
> command.

I know, but have not a accent to support it. ;-)

> Yes, I have a small newlib/libgloss based system without vfork. It's
> an ARM7 (Atmel AT91). uClinux has been ported to it, but the
> constraints are tight: 1 MB SRAM and 2 MB flash. I think it would be
> possible to run uClinux on this system -- I have seen the kernel
> start, at the least -- but there wouldn't be much room left for the
> application.

My patchs for busybox fork()->vfork is help for:
1) spawn as fork+pipe+exec. See tar or xargs.
2) make background for daemons: fork->vfork+exec. See vfork_daemon_rexec().
I think, your vfork->setjmp can`t help for this.
Only fork()+exec+wait and without pipe usage? And have problem with clear BSS.
I think it is not usable, and is shadow problem only.


--w
vodz