udhcp_insert_new_option treats code for IPv6 as follows:
new->data[D6_OPT_CODE] = code >> 8;
new->data[D6_OPT_CODE + 1] = code & 0xff;
udhcp_find_option tests the code as follows:
while (opt_list && opt_list->data[OPT_CODE] < code)
...
if (opt_list && opt_list->data[OPT_CODE] == code)
So yes, OPT_CODE and D6_OPT_CODE are both 0, but the D6_OPT_CLIENTID =
1 value means that the 1 is in the seconds byte, and udhcp_find_option
is only looking at the first byte, So the send_d6_release can never
find it the created option.
function old new delta
udhcp_find_option 28 53 +25
attach_option 276 284 +8
udhcpc6_main 2602 2607 +5
perform_d6_release 262 267 +5
udhcpd_main 1518 1520 +2
udhcpc_main 2542 2544 +2
add_serverid_and_clientid_options 46 48 +2
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 7/0 up/down: 49/0) Total: 49 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
To check if libcrypt and librt are available, we check if we can
compile and link a simple test program.
These checks do not match the actual linking if CONFIG_STATIC is enabled.
For CONFIG_STATIC, CFLAGS_busybox is set to -static. The checks don't use
CFLAGS_busybox and detect a shared libcrypt or librt. If we link busybox
later and we have no static libcrypt or librt, linking will fail.
Update the libcrypt and librt checks to use CFLAGS_busybox.
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
After more testing, (1) I'm more sure it is indeed correct, and
(2) it is a significant speedup - we do a lot of those multiplications.
function old new delta
sp_512to256_mont_reduce_8 191 223 +32
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Change sp_256to512z_mont_{mul,sqr}_8 to not require/zero upper 256 bits.
There is only one place where we actually used that (and that's why there
used to be zeroing memset of top half!). Fix up that place.
As a bonus, 256x256->512 multiply no longer needs to care for
"r overlaps a or b" case.
This shrinks sp_point structure as well, not just temporaries.
function old new delta
sp_256to512z_mont_mul_8 150 - -150
sp_256_mont_mul_8 - 147 +147
sp_256to512z_mont_sqr_8 7 - -7
sp_256_mont_sqr_8 - 7 +7
sp_256_ecc_mulmod_8 494 543 +49
sp_512to256_mont_reduce_8 243 249 +6
sp_256_point_from_bin2x32 73 70 -3
sp_256_proj_point_dbl_8 353 345 -8
sp_256_proj_point_add_8 544 499 -45
------------------------------------------------------------------------------
(add/remove: 2/2 grow/shrink: 2/3 up/down: 209/-213) Total: -4 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
It worked by chance because the only caller passed both parameters
as two pointers to the same array.
My fault (I made this error when converting from 26-bit code).
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Previous change made it obvious that we zero out already-zeroed high bits
function old new delta
sp_256_ecc_mulmod_8 534 494 -40
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The --renumber-inodes option renumbers the inodes starting from 1,
so that the sequence of inodes is always stable. This helps with
reproducibility.
function old new delta
cpio_o 961 1045 +84
.rodata 78422 78440 +18
bbconfig_config_bz2 6168 6164 -4
packed_usage 25764 25756 -8
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 2/2 up/down: 102/-12) Total: 90 bytes
Signed-off-by: Ariadne Conill <ariadne@dereferenced.org>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The --ignore-devno option is used to set device numbers to (0, 0).
This can be useful in verifying whether a CPIO archive is reproducible.
function old new delta
cpio_o 922 961 +39
.rodata 78407 78422 +15
bbconfig_config_bz2 6161 6167 +6
packed_usage 25770 25764 -6
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 3/1 up/down: 60/-6) Total: 54 bytes
Signed-off-by: Ariadne Conill <ariadne@dereferenced.org>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Even though formally it is -s [ARGS], "sh -s" without ARGS
is the same as just "sh". And we are already over 80 chars wide
for ash --help, so make it shorter.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
POSIX.1-2008 mandates the following regarding the write command:
If the command is successful, the number of bytes written shall
be written to standard output, unless the -s option was
specified, in the following format:
"%d\n", <number of bytes written>
function old new delta
readLines 447 409 -38
doCommands 1940 1889 -51
.rodata 104219 104163 -56
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 0/3 up/down: 0/-145) Total: -145 bytes
Signed-off-by: Sören Tempel <soeren+git@soeren-tempel.net>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
- This can act as memory barrier in clang to avoid
read before assign of a const ptr
Signed-off-by: LoveSy <shana@zju.edu.cn>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
This trivial patch makes ${s:...} at least as fast as ${s#??..}
in simple tests. It's probably faster for longer substrings,
but then one wouldn't use ${s#"1024???s"} anyway -
one would switch away from sh.
function old new delta
subevalvar 1457 1503 +46
Signed-off-by: Alin Mr <almr.oss@outlook.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Add some tests which coreutils realpath pass but BusyBox realpath
fails (bar one). Adjust xmalloc_realpath_coreutils() so the tests
pass:
- Expand symbolic links before testing whether the last path component
exists.
- When the link target is a relative path canonicalize it by passing
it through xmalloc_realpath_coreutils() as already happens for
absolute paths.
- Ignore trailing slashes when finding the last path component and
correctly handle the case where the only slash is at the start of
the path. This requires ignoring superfluous leading slashes.
- Undo all changes to the path so error messages from the caller show
the original filename.
function old new delta
xmalloc_realpath_coreutils 214 313 +99
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
