Hi,
I just re-reviewed the patch I just sent...and it needed to be BUFSIZ-3 in
dos2unix.c . tempFn is BUFSIZ so the last addressable spot it BUFSIZ-1. The loop
increments by 2. That's why it should be BUFSIZ-3.
Best Regards,
Steve Grubb
Hello,
I found and patched 2 more bugs. The first is a misplaced semi-colon. The second
one is a buffer overflow. I doubt the buffer overflow is triggered in real life.
But you never know what those wily hackers are up to.
Thanks,
Steve Grubb
This is a bulk spelling fix patch against busybox-1.00-pre10.
If anyone gets a corrupted copy (and cares), let me know and
I will make alternate arrangements.
Erik - please apply.
Authors - please check that I didn't corrupt any meaning.
Package importers - see if any of these changes should be
passed to the upstream authors.
I glossed over lots of sloppy capitalizations, missing apostrophes,
mixed American/British spellings, and German-style compound words.
What is "pretect redefined for test" in cmdedit.c?
Good luck on the 1.00 release!
- Larry
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
Current `tr' implementation has a problem, if `plain char' is signed.
[current cvs version]
>echo a | _install/usr/bin/tr '\0' '\377'
Segmentation fault (core dumped)
[patched version]
>echo a | _install/usr/bin/tr '\0' '\377'
a
Hello,
when calling seq with
seq 1 1
it generates an "endless" list of numbers until the counter wraps and
reaches 1 again. The follwoing small patch should introduce the
expected behavior (output of 1 and termination):
regards,
Jean
uuencode fails to encode binary data because it right-shifts
bytes as signed chars and keeps the duplicated sign bits.
The original base64_encode() from wget/http.c is broken as well,
but it is only used to encode ascii data.
-- Pascal
archive_xread can be replaced with bb_full_read, and archive_copy_file
with bb_copyfd*
bb_copyfd is split into two functions bb_copyfd_size and bb_copyfd_eof,
they share a common backend.
