| Age | Commit message (Collapse) | Author |
|---|
|
*: s/include "busybox.h"/include "libbb.h"
|
|
(by "Kirill K. Smirnov" <lich@math.spbu.ru>)
|
|
Put big scary warnings in relevant places.
|
|
|
|
|
|
|
|
|
|
libbb: rename xgetcwd and xreadlink
|
|
no preceding prototype
|
|
ls: use fully-buffered stdout (can it be problematic
on VERY slow/hanging NFS mounts?)
|
|
|
|
last xcalloc replaced by xzalloc
|
|
(disabling them saves ~4K on fully configured bbox)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It is impossible to formulate sane ABI based on
size of ulong because it can be 32-bit or 64-bit.
Basically it means that you cannot portably use
more that 32 option chars in one call anyway...
Make it explicit.
|
|
|
|
were using "1" as one of the arguments anyway, and as for the rest a multiply
and a push isn't noticeably bigger than pushing two arguments on the stack.
|
|
things like xasprintf() into xfuncs.c, remove xprint_file_by_name() (it only
had one user), clean up lots of #includes... General cleanup pass. What I've
been doing for the last couple days.
And it conflicts! I've removed httpd.c from this checkin due to somebody else
touching that file. It builds for me. I have to catch a bus. (Now you know
why I'm looking forward to Mercurial.)
|
|
Got both to a decent stopping point. (There's a lot more cleanup to do on ls.c
but now is not the time...)
|
|
that and callers wind up typecasting it back.
|
|
- duplicated format bit 14 forced LIST_EXEC always-on
- -p option was behaving just like -F (SUSv3 says -p only shows / for
dirs, not other special symbols)
- tests for LIST_EXEC in color functions were nonsense (constant
tests). i assume they were supposed to be (all_fmt & LIST_EXEC)
however having coloring of executable files depend on -F seems
undesirable.
|
|
- dpkg.c, diff: use xstat
text data bss dec hex filename
848823 9100 645216 1503139 16efa3 busybox_old
848679 9100 645216 1502995 16ef13 busybox_unstripped
bloatcheck is completely useless as it sees -79 for this, which is bogus.
|
|
|
|
|
|
ls has an ugly bug. ls uses an array of pointers, the elements of
which are all in a linked list. To free the elements, instead of
freeing all the elements in the array, array[0..nelements], it frees
by iterating the linked list starting at array[0], which it assumes is
the head of the list. Unfortunately, ls also sorts the array! So,
array[0] is no longer the head, but somewhere in the middle of the
linked list. This patch fixes this bug, and also adds an
ENABLE_FEATURE_CLEAN_UP stanza.
|
|
text data bss dec hex filename
889445 9392 1035784 1934621 1d851d busybox.gcc-4.2.orig
889297 9392 1035784 1934473 1d8489 busybox.gcc-4.2
889009 9820 1037860 1936689 1d8d31 busybox.gcc-4.1.orig
888817 9820 1037860 1936497 1d8c71 busybox.gcc-4.1
|
|
|
|
definitions. (That should only be on prototypes.)
|
|
|
|
yet more incorrect types
|
|
|
|
|
|
my_getpwnam -> bb_xgetpwnam /* dies on error */
my_getgrnam -> bb_xgetgrnam /* dies on error */
my_getgrgid -> bb_getgrgid
my_getpwuid -> bb_getpwuid
my_getug -> bb_getug
|
|
getopt.h, whitespace changes, typos, etc.
|
|
- small indent corrections
- remove unecessary malloc and free
|
|
0000071: patch: implement "--color" option for ls coloring control
|
|
|
|
|
|
Hi,
I've spent the half night staring at the devilish my_getpwuid and my_getgrgid functions
trying to find out a way to avoid actual and future potential buffer overflow problems
without breaking existing code.
Finally I've found a not intrusive way to do this that surely doesn't break existing code
and fixes a couple of problems too.
The attached patch:
1) changes the behaviour of my_getpwuid and my_getgrgid to avoid potetntial buffer overflows
2) fixes all occurences of this function calls in tar.c , id.c , ls.c, whoami.c, logger.c, libbb.h.
3) The behaviour of tar, ls and logger is unchanged.
4) The behavior of ps with somewhat longer usernames messing up output is fixed.
5) The only bigger change was the increasing of size of the buffers in id.c to avoid
false negatives (unknown user: xxxxxx) with usernames longer than 8 chars.
The value i used ( 32 chars ) was taken from the tar header ( see gname and uname).
Maybe this buffers can be reduced a bit ( to 16 or whatever ), this is up to you.
6) The increase of size of the binary is not so dramatic:
size busybox
text data bss dec hex filename
239568 2300 36816 278684 4409c busybox
size busybox_fixed
text data bss dec hex filename
239616 2300 36816 278732 440cc busybox
7) The behaviour of whoami changed:
actually it prints out an username cut down to the size of the buffer.
This could be fixed by increasing the size of the buffer as in id.c or
avoid the use of my_getpwuid and use getpwuid directly instead.
Maybe this colud be also remain unchanged......
Please apply if you think it is ok to do so.
The diff applies on today's cvs tarball (2004-08-25).
Thanks in advance,
Ciao,
Tito
|
|
dev_t. This is especially important now that the user space concept of a dev_t
and the kernel concept of a dev_t are divergant. The only bit of user space
allowed to know the number of major and minor bits is include/sys/sysmacros.h
(i.e. part of libc). When used with a current C library and a 2.6.x kernel,
this fix should allow BusyBox to support wide device major/minor numbers.
-Erik
|
|
s/fileno\(stdout\)/STDOUT_FILENO/g
|
|
I've noticed a bug in the "autowidth" feature more, and is probably in
others. The call to the function get_terminal_width_height() passes
in a file descriptor but that file descriptor is never used, instead
the ioctl() is called with 0. In more_main() the call to
get_terminal_width_height() passes 0 as the file descriptor instead of
fileno(cin). This isn't a problem when you more a file (e.g. "more
/etc/passwd") but when you pipe a file to it (e.g. "cat /etc/passwd |
more") the size of the terminal cannot be determined because file
descriptor 0 is not a terminal. The fix is simple, I've attached a
patch for more.c and get_terminal_width_height.c.
BAPper
|
|
|
|
|
