------------------------
Busybox can always use improvement! If you're looking for ways to help, there
-there are a variety of areas where you could help.
+are a variety of areas where you could help.
What Busybox Doesn't Need
If you find bugs, please submit a detailed bug report to the busybox mailing
list at busybox@busybox.net. A well-written bug report should include a
transcript of a shell session that demonstrates the bad behavior and enables
-anyone else to duplicate the bug on their own machine. The following is such
+anyone else to duplicate the bug on their own machine. The following is such
an example:
To: busybox@busybox.net
$ date
llegal instruction
- I am using Debian unstable, kernel version 2.4.19-rmk1 on an Netwinder,
+ I am using Debian unstable, kernel version 2.4.19-rmk1 on an Netwinder,
and the latest uClibc from CVS. Thanks for the wonderful program!
-Diligent
is very Perl-specific, but the advice given in here applies equally well to
C.
- - C library funciton use audits: Verifying that functions are being used
+ - C library function use audits: Verifying that functions are being used
properly (called with the right args), replacing unsafe library functions
with safer versions, making sure return codes are being checked, etc.
- "Ten Commandments" compliance: (this is a "maybe", certainly not as
important as any of the previous items.)
- http://www.lysator.liu.se/c/ten-commandments.html
+ http://www.lysator.liu.se/c/ten-commandments.html
Other useful links:
changes directly to CVS. This is nice because you don't have to wait for
someone else to commit your change for you, you can just do it yourself.
-But note that this is a priviledge that comes with some responsibilities. You
+But note that this is a privilege that comes with some responsibilities. You
should test your changes before you commit them. You should also talk to an
applet maintainer before you make any kind of sweeping changes to somebody
else's code. Big changes should still go to the mailing list first. Remember,