`dev_t` is already 64-bit in glibc, but on some platforms like Alpine
Linux and Android NDK, `makedev` is defined as more than 32-bit (
promoting to `unsigned long long` then left-shifting by 32bit), while
`dev_t` is still 32-bit.
Since 18a036a613 building on alpine fails
because usage of `__u32`, which is not portable.
> file.c: In function 'rb_stat_new':
> file.c:546:33: error: '__u32' undeclared (first use in this function)
> # define CP_32(m) .stx_ ## m = (__u32)st->st_ ## m
wasi-libc 22 and later support realpath(3)
(https://github.com/WebAssembly/wasi-libc/pull/463) but the underlying
host syscall may return ENOTSUP. This is typically the case when using
incomplete WASI polyfills on web browsers. For such cases, we should
fallback to the emulated realpath.
macOS 15.0 24A5331b seems to have a weird issue that
`CFStringCreateWithBytesNoCopy` does not return `NSTaggedPointerString`
instance for the first call. This issue is fixed in macOS 15.1 but we
need to workaround it for macOS 15.0.
This does not change any actual behaviour, but provides a choke point for blocking IO operations.
* Update `IO::Buffer` to use `rb_io_blocking_region`.
* Update `File` to use `rb_io_blocking_region`.
* Update `IO` to use `rb_io_blocking_region`.
Do not release GVL around get{pwuid,pwnam,grgid,grnam} calls,
as doing so is not thread-safe. Another C extension could have
a concurrent call, and derefencing the returned pointer from
these calls could result in a segfault.
Have rb_home_dir_of call rb_getpwdirnam_for_login if available,
so it can use getpwnam_r and release GVL in a thread-safe manner.
This is related to GVL releasing work in [Bug #20587].
As `__has_attribute` macro is always defined in internal/compilers.h,
gcc warns `-Wunguarded-availability-new` as unknown option. Check if
the warning option is usable instead.
* Release GVL for fdopendir calls
* Release GVL for readdir calls
* Release GVL for chdir call in dir_chdir0
* Release GVL for fchdir call in dir_fchdir
* Release GVL for chroot calls
* Release GVL for lstat calls
* Release GVL for stat calls
* Release GVL for fstatat calls
* Release GVL for getpwnam call in rb_home_dir_of
(technically in file.c, but called from dir.c)
This does not release GVL for readdir/stat/lstat on Windows,
as that causes issues because the emulation functions that
are called in win32.c require the GVL.
This also removes some explicit casts either to or from void *,
which are allowed implicitly. The remaining casts to or from
void * are part of function pointer casts, which are not
allowed implicitly and will generate a warning.
File.expand_path leaks the dir if the encodings are not compatible.
For example:
Encoding.default_external = Encoding::UTF_16BE
10.times do
100_000.times do
File.expand_path("./a")
rescue
end
puts `ps -o rss= -p #{$$}`
end
Before:
12288
15488
18656
21872
25056
28240
31392
34688
37856
41056
After:
9680
9728
9728
9792
9792
9792
9792
9792
9792
* Add rb_io_path and rb_io_open_descriptor.
* Use rb_io_open_descriptor to create PTY objects
* Rename FMODE_PREP -> FMODE_EXTERNAL and expose it
FMODE_PREP I believe refers to the concept of a "pre-prepared" file, but
FMODE_EXTERNAL is clearer about what the file descriptor represents and
aligns with language in the IO::Buffer module.
* Ensure that rb_io_open_descriptor closes the FD if it fails
If FMODE_EXTERNAL is not set, then it's guaranteed that Ruby will be
responsible for closing your file, eventually, if you pass it to
rb_io_open_descriptor, even if it raises an exception.
* Rename IS_EXTERNAL_FD -> RUBY_IO_EXTERNAL_P
* Expose `rb_io_closed_p`.
* Add `rb_io_mode` to get IO mode.
---------
Co-authored-by: KJ Tsanaktsidis <ktsanaktsidis@zendesk.com>
