Based on patch by Paul B. Henson <henson@acm.org>
function old new delta
static.size_suffixes - 32 +32
ubi_tools_main 1141 1148 +7
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
"losetup -d" was not complaining that LOOPDEV is missing.
"losetup -a" was listing only up to /dev/loop9.
"losetup -f" looped forever if llop0 was taken, and never tried
anything after /dev/loop9.
"-o" with other options (say, -r) had no effect.
function old new delta
losetup_main 376 419 +43
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Busybox lsof used the d_type field of a 'struct dirent' to verify whether the
entry is a symbolic link. This field, however, is not portable. On at least
one board [1] I have seen, that field is 0, and the check fails even though
the entry is a link.
The explicit check for a symbolic link is really only needed to skip the
default directory entries '.' and '..'. The directory /proc/<pid>/fd/
should not contain anything else but these two and symbolic links.
With these assumptions, this patch replaces the explicit link check with a
basic check for '.' and '..' (and any hidden file). In the unlikely case that
there are other file types, xmalloc_readlink() will return NULL, and we can
skip the entry.
[1] A MIPS-based board with glibc 2.9, Linux 2.6.32.27.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
If the target can tolerate these issues, then gcc is smart enough
to generate the same code (x86_64 produces the same code). If the
target can't, then it needs the memcpy anyways.
libbb/hash_md5_sha.c: In function 'common64_end':
libbb/hash_md5_sha.c:87:4: warning:
dereferencing type-punned pointer will break strict-aliasing rules
*(uint64_t *) (&ctx->wbuffer[64 - 8]) = t;
libbb/hash_md5_sha.c: In function 'sha512_end':
libbb/hash_md5_sha.c:886:4: warning:
dereferencing type-punned pointer will break strict-aliasing rules
*(uint64_t *) (&ctx->wbuffer[128 - 8]) = t;
libbb/hash_md5_sha.c:889:4: warning:
dereferencing type-punned pointer will break strict-aliasing rules
*(uint64_t *) (&ctx->wbuffer[128 - 16]) = t;
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
This also fixes a minor buffer overflow when displaying threads as
add_proc() only expects COMM_LEN bytes, but we give it one more than
that.
Reported-by: Dag Wieers <dag@wieers.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The current password checking is unable to distinguish between the user
entering an empty password or pressing Control-D. As a result, an empty
password always results in normal startup.
We modify bb_ask to return NULL if Control-D is pressed without entering
a password. The sulogin applet is then modified to only proceed to
normal startup if bb_ask returns NULL. This covers EOF with no password,
interrupt by timeout and ^C.
Signed-off-by: Jonathan Liu <net147@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
When -F isn't specified (and !ENABLE_EXTRA_COMPAT), grep -x uses
regexec's regmatch_t output to determine if the match was the entire
line. However it also set the REG_NOSUB flag which makes it ignore the
regmatch_t argument.
Add an exception to the setting of REG_NOSUB for OPT_x and add some test
cases to test the behaviour of -x.
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Natanael Copa <ncopa@alpinelinux.org>
Cc: Denys Vlasenko <vda.linux@googlemail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
516530c932 uses $DEVNAME variable
for device node name. This is fine, but only works for hotplugging,
"mdev -s" will behave differently when DEVNAME and basename(path)
differ.
This patch extracts the DEVNAME from the uevent sysfs file in
make_device(), thus works for hot- and coldplugging; so using
the environment DEVNAME on hotplug events is no longer necessary.
Signed-off-by: Nikolaus Voss <n.voss@weinmann.de>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
len is declared as uint32_t but le16_to_cpu macro is used
Signed-off-by: Oliver Metz <oliver.metz@gmx.de>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
