Some 32-bit architectures no longer have the 32-bit time_t syscalls.
Instead they have suffixed syscalls that returns a 64-bit time_t. If
the architecture doesn't have the non-suffixed syscall and is using a
64-bit time_t let's use the suffixed syscall instead.
This fixes build issues when
Some 32-bit architectures no longer have the 32-bit time_t syscalls.
Instead they have suffixed syscalls that returns a 64-bit time_t. If
the architecture doesn't have the non-suffixed syscall and is using a
64-bit time_t let's use the suffixed syscall instead.
This fixes build issues when
Some 32-bit architectures no longer have the 32-bit time_t syscalls.
Instead they have suffixed syscalls that returns a 64-bit time_t. If
the architecture doesn't have the non-suffixed syscall and is using a
64-bit time_t let's use the suffixed syscall instead.
This fixes build issues when
Busybox currently manually calls the clock_gettime syscall in some
cases. This causes breakages on y2038 safe 32-bit architectures such as
32-bit RISC-V. To fix this breakage let's add some #ifdefs around the
syscalls to call the __NR_clock_gettime64 if we don't have
__NR_clock_gettime defined and
Hi,
On Tue, Sep 03, 2019 at 10:31:20AM +0800, Kang-Che Sung wrote:
> gzip -9 is quite fast in modern processors, and if someone builds busybox
> without CONFIG_FEATURE_GZIP_LEVELS, I think they are moke likely to stick
> with -9 as default instead of -6.
No, -9 is really slow with little gain:
The process created by vfork() needs to _exit() instead of showing a potential error since it is an undefined behavior. So are calling the functions before execlp().From 'man vfork()': "Standard description (From POSIX.1) The vfork() function has the same effect as fork(2), except that the
Op 03-09-19 om 04:31 schreef Kang-Che Sung:
Excuse me, but I wonder one thing on the third patch: Why should we follow
strictly with gzip on the no-options default behavior?
For two reasons.
First, the default 6 compression level is a de-facto standard. BSD gzip
and Apple gzip (on macOS) use
I split out the third patch for this reason. I agree, it can be dropped
if people see no need for it. Adding a compile-time option I think is
overkill.
Daniel
On 03/09/2019 04.31, Kang-Che Sung wrote:
>> From 12d30559486502feec4e2821b3ab45ae6139e7aa Mon Sep 17 00:00:00 2001
>> From: Daniel
