Documentation on Linux explains that nul bytes have no
special significance in abstract namespace socket names.
Avoid precluding such addresses.
Signed-off-by: Itay Bookstein <ibookstein@gmail.com>
Windows provides the `ENABLE_VIRTUAL_TERMINAL_INPUT` flag for TTY input
streams as a companion flag to `ENABLE_VIRTUAL_TERMINAL_PROCESSING`,
which libuv is already setting for TTY output streams.
Setting this flag lets the terminal emulator perform some of the
processing that libuv already currently does for input events,
but most notably enables receiving control sequences that are
otherwise entirely unavailable, e.g. for bracketed paste
(which the Node.js readline implementation added basic support for
in https://github.com/nodejs/node/commit/87af913b66eab78088acfd).
libuv currently already provides translations for key events to
control sequences, i.e. what this mode is intended to provide,
but libuv does not and cannot translate all such events.
Since the control sequences differ from the ones that Windows
has chosen to standardize on, and applications may not be expecting
this change, this is opt-in for now (but ideally will be the default
behavior starting in libuv v2.x, should that ever happen).
Another downside of this change is that not all shells reset
this mode when an application exits. For example, when running a
Node.js program with this flag enabled inside of PowerShell in
Windows terminal, if the application exits while in raw TTY input mode,
neither the shell nor the terminal emulator reset this flag, rendering
the input stream unusable.
While there's general awareness of the problem that console state is
global state rather than per-process (same as on UNIX platforms),
it seems that applications like PowerShell aren't expecting to need to
unset this flag on the input stream, only its output counterpart
(e.g. 4e7942135f/src/Microsoft.PowerShell.ConsoleHost/host/msh/ConsoleHost.cs (L1156)).
Hence, `uv_tty_reset_mode()` is extended to reset the terminal
to its original state if the new mode is being used.
Refs: 87af913b66
Refs: https://github.com/microsoft/terminal/issues/4954
Extend uv_fs_utime, uv_fs_futime and uv_fs_lutime to accept NAN and
INFINITY, with NAN meaning "don't touch the timestamp" and INFINITY
meaning "set to the current timestamp."
Ugly, but it avoids having to add uv_fs_utime2, etc.
UV_FS_UTIME_NOW and UV_FS_UTIME_OMIT constants have been added to make
it more palatable.
Fixes: https://github.com/libuv/libuv/issues/4665
This patch will update Android API in CI to 29 and will set up the fdsan
in the test runner.
Signed-off-by: Juan José Arboleda <soyjuanarbol@gmail.com>
Fixes: https://github.com/libuv/libuv/issues/4369
Replace comparison of `alloc_cb_called` with the total bytes
read (`bytes_read`) to validate the test's correctness.
Fixes: https://github.com/libuv/libuv/issues/4650
Signed-off-by: Juan José Arboleda <soyjuanarbol@gmail.com>
Add a version of uv_udp_try_send that can send multiple datagrams.
Uses sendmmsg(2) on platforms that support it (Linux, FreeBSD, macOS),
falls back to a regular sendmsg(2) loop elsewhere.
This work was sponsored by ISC, the Internet Systems Consortium.
`uv_thread_setname()` sets the name of the current thread. Different
platforms define different limits on the max number of characters
a thread name can be: Linux, IBMi (16), macOS (64), Windows (32767),
and NetBSD (32), etc. `uv_thread_setname()` will truncate it in case
`name` is larger than the limit of the platform.
`uv_thread_getname()` gets the name of the thread specified by `tid`.
The thread name is copied into the buffer pointed to by `name`. The
`size` parameter specifies the size of the buffer pointed to by `name`.
The buffer should be large enough to hold the name of the thread plus
the trailing NUL, or it will be truncated to fit.
This commit introduces the `uv_thread_detach` for thread detaching,
allowing threads to be detached state on both UNIX and Windows platforms.
Signed-off-by: Juan José Arboleda <soyjuanarbol@gmail.com>
For any API that takes a buffer and size pointer, check both pointers
and the pointed-to size and return UV_EINVAL in case of error.
Example:
```
int uv_foo(char* buffer, size_t* size) {
if (buffer == NULL || size == NULL || *size == 0)
return UV_EINVAL;
...
}
```
In order to "peek" the necessary size for dynamic allocation, the
following pattern can be used:
```
char *buf;
char scratch[1];
size_t len = sizeof(scratch);
int r;
r = uv_foo(scratch, &len);
assert(r == UV_ENOBUFS);
buf = malloc(len);
r = uv_foo(buf, &len);
...
```
Requires updating the android builder, since the arm emulator is
deprecated and unavailable now. Switch to using a Github Action plugin
instead of a container, so that hopefully future updates will be
delivered via that channel instead.
Changed the idna test since printf returns EILSEQ for some byte
sequences in the format on Android in glibc. We don't fully understand
the cause, but we can avoid that by not asking it to reencode the bytes
in the current locale settings.
uv_wtf8_length_as_utf16() checks if codepoints are > 0xFFFF (to see if
it should be encoded as a surrogate pair), therefore uv_wtf8_to_utf16()
should too. Instead it checked > 0x1000. Harmonize the checks.
Fixes: https://github.com/nodejs/node/issues/55914
It happens due to the default firewall configuration on macOS >= 13.
Note: GH action runners have their firewall disabled, and yet, the test
fails all the same. Oh well...
Closes: https://github.com/libuv/libuv/issues/4263
It seemed incorrect to map a segfault to EACCES, since posix would typically
map this to EFAULT. The ERROR_BUFFER_OVERFLOW is literally "the filename is too
long", and is not typically an invalid parameter in posix.
Test originally added in #1060 to test the API, not the value.
After commit 18266a6969, it changed to return `ENOTDIR`, which makes it
consistent with other platforms but it also can be considered a breaking
change.
Delete the fs_event_error_reporting test. It fails in different ways,
most frequently on the TSan sanitizer buildbot, due to running out of
file descriptors when that is not expected, or vice versa, *not*
running out of file descriptors when that *is* expected.
The test creates a large number of event loops and expects to,
eventually, hit EMFILE but it sometimes hits it too early, and
sometimes not at all.
I don't think TSan is really responsible here, it just makes the
invalid assumption in the test itself more visible.
Fixes: https://github.com/libuv/libuv/issues/4368
Autobinding is a feature that lets the kernel pick a name for the
abstract socket, instead of userspace having to provide one.
Two bugs that this change exposed are also fixed:
1. strlen(sa.sun_path) can read past the end if the file path is exactly
sizeof(sa.sun_path) long (use memchr instead), and
2. don't return UV_ENOBUFS for abstract sockets when the buffer is
exactly large enough to hold the result; per commit e5f4b79809,
abstract socket names are not zero-terminated
MSVC does not actually support ubsan. There is a long-standing ticket
requesting this:
https://developercommunity.visualstudio.com/t/add-support-for-ubsan/840750
There are no known compilers that currently accept the
`/fsanitize=undefined` spelling. clang-cl accepts `-fsanitize...`,
same as regular clang.
Also passes no-sanitizer-recover so that tests actually fail.
Fix various ubsan-detected errors, including:
* win: fix req-inl.h ubsan failure
Don't use CONTAINING_RECORD macro from WinSDK, as it doesn't use the
right trick which avoids member access on null pointer.
Fixes:
```
src/win/req-inl.h:86:10: runtime error: member access within null pointer of type 'uv_req_t' (aka 'struct uv_req_s')
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior D:/a/libuv/libuv/src/win/req-inl.h:86:10
```
* test: fix ubsan failure on udp_ref3
Don't call functions through different function type.
Fixes:
```
src/win/udp.c:537:5: runtime error: call to function req_cb through pointer to incorrect function type 'void (*)(struct uv_udp_send_s *, int)'
test\test-ref.c:66: note: req_cb defined here
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior src/win/udp.c:537:5 in
```
* win: fix process-stdio.c ubsan failure
When accessing HANDLEs within the stdio buffer, use memcpy / memset in order to respect alignment.
Fixes:
```
src/win/process-stdio.c:197:5: runtime error: store to misaligned address 0x0230ee72d107 for type 'HANDLE' (aka 'void *'), which requires 8 byte alignment
0x0230ee72d107: note: pointer points here
00 00 cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd fd fd fd fd
^
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior src/win/process-stdio.c:197:5 in
```
* win: fix getaddrinfo.c ubsan failure
Reworks buffer alignment handling to respect requirements.
Fixes:
```
src/win/getaddrinfo.c:157:23: runtime error: member access within misaligned address 0x0290e4c6a17c for type 'struct addrinfo', which requires 8 byte alignment
0x0290e4c6a17c: note: pointer points here
00 00 00 00 cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd
^
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior src/win/getaddrinfo.c:157:23 in
```
* win: fix pipe.c ubsan failure
Changes "random" representation from pointer to number.
Fixes:
```
src/win/pipe.c:234:11: runtime error: applying non-zero offset to non-null pointer 0xffffffffffffffff produced null pointer
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior src/win/pipe.c:234:11 in
```
* unix: fix stream.c ubsan failure
Avoids performing pointer arithmetic on null pointer.
Fixes:
```
src/unix/stream.c:701:15: runtime error: applying zero offset to null pointer
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /Users/runner/work/libuv/libuv/src/unix/stream.c:701:15 in
```
If the corresponding environment variables are empty, the
uv_us_homedir() and uv_os_tmpdir() return garbage values. The reason
for this situation is the Windows API which doesn't return an error
even if the path is empty.
This PR fixes this problem by checking the return value of the API
call. If it is not an error and the length of the value is less than 3,
uv_us_homedir() and uv_os_tmpdir() will return UV_ENOENT.
Fixes: https://github.com/libuv/libuv/issues/2328
Under rare but benign circumstances (on XNU), incoming datagrams appear
to be dropped by the operating system after libuv has been notified of
their arrival but before libuv has had a chance to receive them.
Fixes: https://github.com/libuv/libuv/issues/4219
This commit changes the timestamps in the file, the ownership and the
group.
Fixes: https://github.com/libuv/libuv/issues/3125
Signed-off-by: Juan José Arboleda <soyjuanarbol@gmail.com>
Should hopefully make it easier to debug CI flakiness because
currently the test sometimes fails without a clear indication why.
Refs: https://github.com/libuv/libuv/issues/4106
