The arm64 architecture never had a _sysctl system call and therefore
doesn't have a SYS__sysctl define either. Always return UV_ENOSYS.
Fixes: https://github.com/libuv/libuv/issues/2522
PR-URL: https://github.com/libuv/libuv/pull/2524
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
This commit fixes uv_fs_copyfile() in cases where an unknown error
occurs when copy-on-write is requested by setting
UV_FS_COPYFILE_FICLONE. The original approach tried to catch some of
the errors raised by the ioctl() call, assuming that sendfile() would
also fail in those cases. This is not necessarily true, as some
variants of ioctl() also raise EINVAL (some maybe EBADF), but sendfile()
works just fine.
This patch reverses the logic, falling back to sendfile() in any
case where ioctl() returns an error. In other words, it tries much
harder to make uv_fs_copyfile() work.
Related to that, the original approach returned UV_ENOTSUP
unconditionally in cases where ioctl() failed and
UV_FS_COPYFILE_FICLONE_FORCE was set. However, ioctl() may have
failed for other reasons than being not supported. The function
now returns the actual error raised by ioctl(), leaving it to the
caller to deal with it.
Fixes: https://github.com/libuv/libuv/issues/2483
PR-URL: https://github.com/libuv/libuv/pull/2514
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
xlc reportedly doesn't support the `-Wno-long-long` flag. Detect that
at configure time instead of trying to fix it up at build time.
This enables the flag for both the library and the test suite instead
of just the test suite but that seems fine to me.
PR-URL: https://github.com/libuv/libuv/pull/2512
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Otherwise we run the risk of running the timer before the fsevent
callback since the timer due time is "now" because it's as long as the
process already slept.
Refs: https://github.com/libuv/libuv/issues/2491
PR-URL: https://github.com/libuv/libuv/pull/2516
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Update this code to be more in line with the Windows version.
Previously, callers (such as nodejs) might assume it was always safe to de-reference this parameter:
d2634be562/src/tcp_wrap.cc (L349) called from d2634be562/src/udp_wrap.cc (L567)
I suspect this may have been unreachable, and that it was guaranteed by the kernel to be `>= sizeof(struct sockaddr)`, so this should be a NFC simplification.
PR-URL: https://github.com/libuv/libuv/pull/2330
Reviewed-By: Saúl Ibarra Corretgé <s@saghul.net>
Stop dlsym-ing the symbol name at run-time, that was only necessary to
support macOS and iOS versions that were already near-obsolete when this
feature was introduced in August 2013.
PR-URL: https://github.com/libuv/libuv/pull/2480
Reviewed-By: Saúl Ibarra Corretgé <s@saghul.net>
Libuv loaded and unloaded the Core Services and Application Services for
every call to uv_set_process_title().
Change that to load them on the first call to uv_set_process_title() and
delay unloading until libuv is unloaded.
Speeds up process_title_threadsafe by about 10x on my system. It should
fail less often (hopefully not at all) on the CI now.
PR-URL: https://github.com/libuv/libuv/pull/2480
Reviewed-By: Saúl Ibarra Corretgé <s@saghul.net>
Remove duplicated test-ip6-addr.c in cmake build file
and gyp file.
PR-URL: https://github.com/libuv/libuv/pull/2494
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
When cleaning up after uv_fs_readdir(), it is important to
call uv_fs_req_cleanup() on the readdir request prior to calling
uv_fs_closedir(), because the latter frees memory that the
former needs in order to do its job.
PR-URL: https://github.com/libuv/libuv/pull/2497
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
In the fs_readdir_empty_dir test, the uv_fs_readdir() request is
cleaned up after calling uv_fs_closedir(). However, the readdir
request should be cleaned up before calling uv_fs_closedir().
Fixes: https://github.com/libuv/libuv/issues/2496
PR-URL: https://github.com/libuv/libuv/pull/2497
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
FreeBSD defines `sin_len` and `sin6_len` inside `sockaddr_in` and
`sockaddr_in6`. `sockaddr`s come from `getsockname` and `uv_ip4_addr`
will differ in the first byte if libuv doesn't set `sin_len` correctly.
PR-URL: https://github.com/libuv/libuv/pull/2492
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <s@saghul.net>
- Bump CMake version to 3.4 so we can eventually use all the
cool things like better generator expression support, and
`target_sources`, and also better MSVC runtime linkage support
- Reorganize includes to be all in one place.
- Rename libuv_buildtests option to LIBUV_BUILD_TESTS. It is disabled
unless BUILD_TESTING is ON *and* libuv is the "root" project. This helps
projects that might use libuv as a git submodule, or as a download that
is then passed to `add_subdirectory`.
Refs: https://github.com/libuv/libuv/pull/2490
PR-URL: https://github.com/libuv/libuv/pull/2495
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <s@saghul.net>
Test `test-fs.c` fails when built in a relocated directory because
the build does link the required test fixture.
PR-URL: https://github.com/libuv/libuv/pull/2444
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <s@saghul.net>
Reviewed-By: Jameson Nash <vtjnash+github@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Use our builtin getrandom helper instead of the more verbose CryptoAPI
functions, which also happen to be deprecated.
PR-URL: https://github.com/libuv/libuv/pull/2485
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>
Add an API for obtaining cryptographically strong random data from the
system PRNG.
Co-authored-by: Saúl Ibarra Corretgé <s@saghul.net>
Refs: https://github.com/libuv/libuv/pull/1055
PR-URL: https://github.com/libuv/libuv/pull/2347
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
There are some special environment variables on Windows that
start with a '=' sign, e.g. per-drive working directories.
In those cases, an initial '=' in the name of the environment
variable needs to be skipped when looking for the '=' that separates
it from its value.
PR-URL: https://github.com/libuv/libuv/pull/2473
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Jameson Nash <vtjnash+github@gmail.com>
Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
This commit contains a suggestion to hopefully improve the
documentation of uv_handle_t's member uv_loop_t.
PR-URL: https://github.com/libuv/libuv/pull/2446
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
According to http://man7.org/linux/man-pages/man2/open.2.html, the
O_DIRECT flag is Linux-specific. One must define _GNU_SOURCE to obtain
the correct definition.
However, defining _GNU_SOURCE in the headers is unhygienic and affects
the libuv consumer.
On Linux, we now define UV_FS_O_DIRECT explicitly according to
architecture, only falling back to O_DIRECT if defined, or 0 if not.
Fixes: https://github.com/libuv/libuv/issues/2420
PR-URL: https://github.com/libuv/libuv/pull/2441
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Platforms that support O_CLOEXEC have supported it for a long time
and don't need feature detection. Libuv can just assume it works as
advertised.
The feature detection was broken for old Linux kernels because they
don't report EINVAL for unknown open() flags, they simply open the
file without setting the FD_CLOEXEC flag.
Libuv could fix that by checking afterwards with fcntl() if the flag
was actually set but it doesn't support kernels that old in the first
place so let's simplify the logic.
Fixes: https://github.com/libuv/libuv/issues/2450
PR-URL: https://github.com/libuv/libuv/pull/2454
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
