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
While building glibc with busybox as part of the development environment, I
found a bug in glibc's regexec can throw sed into an endless loop. This
fixes it. Should I put an #ifdef around it or something? (Note, this patch
also contains the "this is not gnu sed 4.0" hack I posted earlier, which is
also needed to build glibc...)
out during the allocation process. When vodz changed it to be allocated on the
stack, he forgot to explicitly zero it, leaving its value filled with whatever
used to be sitting on the stack. It would garbage values, depending on the
garbage that happened to be sitting on the stack when the function was called.
The result was that applets using bb_getopt_ulflags() were showing
unpredictable behavior (such as segfaults), which naturally broke many things.
- synced with dash 0.4.21
- better handle trap "cmds..." SIGINT (strange, i make bad hack for ash
and cmdedit, but this work only with this...)
- may be haven`t problem with Ctrl-D
No checking for lines that were too long.
No checking that fgets returning NULL was actually due to EOF.
Various whitespace handling inconsistencies.
Bloat (switches and multiple identical function calls).
Failure to check for trailing characters in some cases.
Dynamicly allocated memory was not free()d on error.
Given that this controls suid/sgid behavior, the sloppy coding was
really inexcusable. :-(
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
bb_lookup_port now takes 3 parameters but rdate has not been modified
accordingly and fails to compile in the current CVS version.
The modification below fixes the problem.
Now, RFC868 allows both UDP and TCP implementations of the time protocol
so this may not work if someone defines a udp time service other than 37
but who would do that?
