Fixes the following compiler warnings:
random.c: In function `random_init`:
random.c:416:38: warning: `rng` may be used uninitialized in this function [-Wmaybe-uninitialized]
416 | unsigned int major = rng->version.major;
| ~~~~~~~~~~~~^~~~~~
random.c: In function `random_bytes`:
random.c:1284:8: warning: `rng` may be used uninitialized in this function [-Wmaybe-uninitialized]
1284 | rng->get_bytes(rnd, ptr, n);
| ~~~^~~~~~~~~~~
random.c:1299:34: note: `rng` was declared here
1299 | const rb_random_interface_t *rng;
| ^~~
random.c: In function `rand_random_number`:
random.c:1606:12: warning: `rng` may be used uninitialized in this function [-Wmaybe-uninitialized]
1606 | return rand_range(obj, rng, rnd, vmax);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
random.c:1624:34: note: `rng` was declared here
1624 | const rb_random_interface_t *rng;
| ^~~
random.c: In function `random_rand`:
random.c:1120:15: warning: `rng` may be used uninitialized in this function [-Wmaybe-uninitialized]
1120 | return rng->get_int32(rnd);
| ~~~^~~~~~~~~~~
random.c:1573:34: note: `rng` was declared here
1573 | const rb_random_interface_t *rng;
| ^~~
* [DOC] Clarify differences between Kernel.rand and Random.rand
* `Kernel.rand` converts the `max` Float argument to Integer and returns Integer values
* `Random.rand` preserves the `max` Float argument and returns Float values
* Added examples demonstrating the behavioral differences
We recently converted this to be WB_PROTECTED, but missed some locations
the seed was set.
This is a little bit confusing because as far as I can tell some of the
seeds are set in Ractor local storage, and others on actual objects.
This is a follow-up to commit b120f5e38d9c (avoid fork-unsafe arc4random
implementations, 2018-09-04).
Avoid defining a no-op fill_random_bytes_syscall() if arc4random_buf(3)
exists, but we are unsure if it is fork-safe. Check for other options
instead. IOW, see if getrandom(2) is available.
glibc 2.36, released in 2022, started to provide arc4random_buf(3) on
Linux. This causes fill_random_bytes_syscall() to use neither of them
and makes Random.urandom solely rely on getentropy(3) via
fill_random_bytes_urandom().
While the glibc implementation is safe, I did not add it to the list
because using getrandom(2) directly is preferable on Linux.
If this is not a system call, then it is using getrandom (which would
have been tried already), and cannot be used as a replacement for the
random devices.
When loading a crafted marshal data of Random, a pointer to an illegal
address was created. I don't think there is any harm since the data is
normalized before access, but just to be safe, I add a check to make it
an error.
Do not retry `fill_random_bytes` in `Init_RandomSeedCore`, just after
it failed first.
In other places, `rand_init_default` and `random_seed`, no more tweeks
needed once it succeeded
This `st_table` is used to both mark and pin classes
defined from the C API. But `vm->mark_object_ary` already
does both much more efficiently.
Currently a Ruby process starts with 252 rooted classes,
which uses `7224B` in an `st_table` or `2016B` in an `RArray`.
So a baseline of 5kB saved, but since `mark_object_ary` is
preallocated with `1024` slots but only use `405` of them,
it's a net `7kB` save.
`vm->mark_object_ary` is also being refactored.
Prior to this changes, `mark_object_ary` was a regular `RArray`, but
since this allows for references to be moved, it was marked a second
time from `rb_vm_mark()` to pin these objects.
This has the detrimental effect of marking these references on every
minors even though it's a mostly append only list.
But using a custom TypedData we can save from having to mark
all the references on minor GC runs.
Addtionally, immediate values are now ignored and not appended
to `vm->mark_object_ary` as it's just wasted space.
when the RUBY_FREE_ON_SHUTDOWN environment variable is set, manually free memory at shutdown.
Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>
Co-authored-by: Peter Zhu <peter@peterzhu.ca>
This is a follow-up for commit 265c0022390e ("Do not allocate
ractor-local storage in dfree function during GC", 2021-02-09).
The comparison with the default rb_random_mt_t is useless in the first
place, since it is never equal: no actual Random object is associated
with it.
[Bug #17653] https://bugs.ruby-lang.org/issues/17653
Security/Authorization.h defines AuthorizationExternalForm by
using clang extension which allows variably modified types in a
file scope. As we just need high-level accessors only, include
Security/SecRandom.h instead.
