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>
Make mktemp more compatible with coreutils.
- add "--tmpdir" option
- add long variants for "d,q,u" options
Note: Upstream ca-certificate update script started using this option.
function old new delta
.rodata 104179 104219 +40
mktemp_main 186 194 +8
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 2/0 up/down: 48/0) Total: 48 bytes
Signed-off-by: Andrej Valek <andrej.valek@siemens.com>
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
range_start was staying -1, and comparison meant to detect
"is it the first sendfile that failed, or not the first?"
was making incorrect decision. The result: nothing is sent.
function old new delta
send_file_and_exit 865 877 +12
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The reported case was an attempt to remount,rw a CD-ROM:
mount -o remount,rw /mnt/sr0
which "succeeded" by falling back to RO:
mount("/dev/sr0", "/mnt/sr0", 0x412862, MS_REMOUNT|MS_SILENT|MS_RELATIME, "nojoliet,check=s,map=n,blocksize"...) = -1 EROFS (Read-only file system)
...
mount("/dev/sr0", "/mnt/sr0", 0x412862, MS_RDONLY|MS_REMOUNT|MS_SILENT|MS_RELATIME, "nojoliet,check=s,map=n,blocksize"...) = 0
Clearly, not what was intended!
function old new delta
parse_mount_options 241 267 +26
mount_main 1198 1211 +13
singlemount 1301 1313 +12
inetd_main 1919 1911 -8
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 3/1 up/down: 51/-8) Total: 43 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>