This is not precisely a strict rule, but this syntax is reinforced in many
large C projects like the Linux kernel and cURL.
Signed-off-by: Juan José Arboleda <soyjuanarbol@gmail.com>
Port 143da93e to Windows: replace the 250 ms settle delay with a pipe-
based synchronization mechanism. The parent creates a pipe, passes the
write-end handle to the helper via UV_TEST_RUNNER_FD, then blocks on
ReadFile() until the helper calls notify_parent_process() and closes its
copy of the handle.
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
When the user calls uv_async_send concurrently with uv_loop_close, we
try to prevent that data race from actually accessing undefined behavior
by setting the pending flag atomically with the busy flag. This was
proposed in the original PR, but we didn't have motivation to go with
this implementation until a user pointed out that it improves behavior
of the race window in more cases.
Reserve one byte for the NUL terminator when passing the buffer size
to uv_utf16_to_wtf8() in the TTY line-read path. Without this, when
all input characters encode to exactly 3 UTF-8 bytes (e.g. CJK) and
the buffer size is divisible by 3, the NUL terminator is written one
byte past the allocated buffer.
The other two call sites in src/win/util.c already subtract 1 before
calling uv_utf16_to_wtf8(). This aligns tty.c with that convention.
Fixes commit f3889085 ("win,tty: convert line-read UTF-16 to WTF-8")
from October 2023.
Refs: https://github.com/libuv/libuv/security/advisories/GHSA-4prr-4742-3ccf
Previously, `uv__udp_io` would proceed to call `uv__udp_recvmsg` for
the `POLLERR` event even if the handle was just closed by the `POLLIN`
callback.
This commit adds a guard to verify the handle is still active before
processing the error queue. It also adds a regression test that
mimics this recursive closure behavior.
Fixes: https://github.com/libuv/libuv/issues/5030
Signed-off-by: Juan José Arboleda <soyjuanarbol@gmail.com>
Fix the casting of const char varaibles with const char returns from
functions, when the data being returned is not being modified. Includes
the part revert of "unix: fix compilation warnings with GCC 15"
This reverts commit 50ed2fd7bd.
Do not cast const char to char unnecessarily. Refactor function to use
char s only when slash is in the path.
Fixes:
[6/73] Building C object CMakeFiles/uv.dir/src/inet.c.o
../src/inet.c: In function 'uv_inet_pton':
../src/inet.c:157:7: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
157 | p = strchr(src, '%');
| ^
Signed-off-by: Rudi Heitbaum <rudi@heitbaum.com>
Fix#4814 by adding const annotation when assigning string literal
"unknown" to `char*` pointer.
This eliminates compiler warnings when building with strict
const-correctness flags like `-Wwrite-strings`.
Add uv__get_rlimit_max_memory() helper that checks RLIMIT_AS and
RLIMIT_DATA resource limits across all Unix platforms. This helper
returns the minimum of these rlimits if set.
Update all Unix platform implementations of uv_get_constrained_memory()
to use this helper, ensuring consistent handling of resource limits:
- Linux: combine cgroup limits with rlimits
- z/OS: combine RLIMIT_MEMLIMIT with rlimits
- Other Unix platforms: use rlimits (previously returned 0)
This provides a more accurate view of available memory when processes
have rlimit constraints in addition to platform-specific limits.
Related: https://github.com/JuliaLang/julia/pull/51656
Co-Authored-By: Claude <noreply@anthropic.com>
clang-tidy can already read the compilation database from cmake to run
on any file. This sets up some cmake targets to make it easier to run
the check on all files applicable to the current platform. It also
disables a few analyses to reduce the number of warnings to a manageable
level. Actually making any fixes is left for later.
some users of libuv rely on uv_exepath to be an actual path to a
program. unfortunately, the OpenBSD KERN_PROC_ARGV sysctl just returns
what is in argv[0], so if the program was executed by being looked up in
$PATH, uv_exepath would only return the basename and not an actual path.
to fix, this use the same approach as IBM i, OS/390 and AIX by searching
with uv__search_path. this is also the same approach the Zig language
has taken for the similar selfExePath function for OpenBSD.
the tests expect that uv_exepath still works after uv_set_process_title,
which on BSD is a call to setproctitle. the place setproctitle stores to
is the same place that KERN_PROC_ARGV reads from, so we need to stash
the original argv[0] in uv_setup_args to recover it later in uv_exepath.
0x10FFFF is the valid max unicode character, so the check should be
inclusive.
This assert gets triggered because uv__wtf8_decode1 (used by
uv_wtf8_length_as_utf16) has the correct code_point <= 0x10FFFF check,
so the sequence is treated as valid and it will be passed into
uv_wtf8_to_utf16, where the incorrect assert gets triggered:
src/idna.c:397: uv_wtf8_to_utf16: Assertion `code_point < 0x10FFFF' failed.
Accomplish this by replacing `GetDiskFreeSpaceW()` with
`NtQueryVolumeInformationFile()` which allows us to represent blocks
larger than 2^32 - 1 via
`FILE_FS_FULL_SIZE_INFORMATION.TotalAllocationUnits`.
Expanded `fs_statfs` test to check that `uv_fs_statfs()` also works with
files, meaning https://github.com/libuv/libuv/issues/2683 remains fixed
without the need of https://github.com/libuv/libuv/pull/2695.
The test is multi-threaded and expects both threads to receive at least
some of the incoming connections but there isn't always true parallelism
under QEMU's user-mode emulator.
Single-core systems are also susceptible to that so also add a check
that we have at least two cores to run on.
As mentioned in the change for the udp_reuseport test from a few days
ago, the test is not perfect (there being > 1 core doesn't guarantee
we actually get to run on them) but it's better than nothing.
Fixes: https://github.com/libuv/libuv/issues/5003
The test is multi-threaded and expects both threads to receive at least
some of the incoming datagrams but there isn't always true parallelism
under QEMU's user-mode emulator.
Single-core systems are also susceptible to that so also add a check
that we have at least two cores to run on.
It's not perfect because a sufficiently dedicated test torturer could
probably concoct a containerized setup where the core count > 1 but the
available CPU slice is so small that the test effectively still runs
sequentially, but it's better than nothing.
Fixes: https://github.com/libuv/libuv/issues/4777
It was reported that PTYs on Linux sometimes report POLLHUP, return a
partial read, but still return more data on the next read.
Libuv contains an optimization where it assumes a partial read after
POLLHUP means the next read can be skipped because it's going to fail
with EOF anyway. That assumption was thought to be always true but,
alas, it isn't.
The fact the optimization has been present for 13 years and this is the
first bug report about it, indicates how rare this particular condition
is, but of course we can't skim on correctness.
The reworked optimization only uses POLLHUP as an input signal when
POLLIN is not also set. That means we no longer have to track partial
reads because we're going to try and read anyway as long as POLLIN is
set. It seems to cause no measurable regressions on the test suite or
the (lightly tested) benchmarks.
Fixes: https://github.com/libuv/libuv/issues/4992
Check the length before doing the compare like we do a few lines below,
not the other way around. It's a false positive because the length is
capped well below the maximum object size but it's an easy fix.
Fixes the following warning:
test/test-poll-oob.c:94:19: warning: ‘strncmp’ specified bound
[18446744071562067968, 18446744073709551615] exceeds maximum
object size 9223372036854775807 [-Wstringop-overread]
