As #6359 pointed out, calling const_missing hook from E_XXX_ERROR (that
calls mrb_exc_get_id()) can be an attack vector. Since E_XXX_ERROR is
supposed to be a defined error class, we think that the situation where
it is undefined and the const_missing hook is called should be detected
as an error; fix#6359
The `mrb_get_argv()` function and the `*` specifier of `mrb_get_args()` get the address of the argument.
At this time, if it is passed in the form of a splat argument, it will be an address to an element of an array object.
After getting the pointer to the array object, the caller may call `mrb_vm_exec()` directly or indirectly.
At this time, a splat argument with the class set can be retrieved as an array object by searching with `ObjectSpace.each_object`.
If changes are made as array objects, addresses on the heap as arrays may become invalid, or objects in the array may be recycled by the GC.
When the caller references the changed address in a subsequent operation, use-after-free is established.
This patch assigns `NULL` as the class of the array object so that it cannot be detected by `ObjectSpace.each_object` from the Ruby side.
Static proc objects defined as methods may be placed in 4-byte alignments in 32-bit environments.
This may be misinterpreted as an immediate value depending on the address.
Since C11 and C++11 have additional language features for byte alignment, corresponding compilers use them to define the `mrb_alignas()` macro.
For earlier compilers, they use their own extensions to define the `mrb_alignas()` macro.
GCC supports `__attribute__((aligned(alignment)))` since at least version 2.95.3 (1999).
https://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#IDX305
According to GPT-4, support was added in version 2.7 (1995).
It is not known which version of Visual C++ added support for `__declspec(align(n))`.
According to GPT-4, at least Visual C++ 6.0 (1998) seems to support it.
Also, the documentation of past Intel C/C++ compilers that support `__declspec(align(n))` makes reference to support with Visual C++ 4.2 (1996).
https://www.intel.com/content/dam/www/public/ijkk/jp/ja/documents/developer/ccomp40j.pdf
The purpose is to remove the `mid` field from the `mrb_cache_entry` structure.
The resulting RAM requirement for the method cache is reduced from 5 words per entry to 4 words per entry for 32-bit CPUs.
The relevant changes are as follows:
- Removed `MRB_USE_METHOD_T_STRUCT`.
The `mrb_method_t` type is now always defined as a structure.
- Include method IDs in `mrb_method_t`
Change the `flags` member to `uint32_t`.
The bitstring structure should be the same as the keys of the `mt` table in `class.c`.
I believe the impact on API compatibility with previous versions is minimal.
This will be a partial merge of #5317 with the following changes.
- Remove `iclass->iv_c` since `iclass->iv_c` is equivalent to `iclass->c`.
- `class_iv_ptr()` returns a single pointer instead of a double pointer.
If `Class#allocate` is prohibited, subclasses should also be implicitly prohibited.
```ruby
p Class.new(Struct).allocate.class
# => #<Class:0x82362ac00> by #6122
# => allocator undefined for #<Class:0x000000083a983220> (TypeError) by Ruby 3.2
```
Added `MRB_DEFINE_ALLOCATOR()` to allow subclasses to use `Class#allocate`.
Supplement to #6122.
The method introduced by #5979 causes a fault by swapping classes.
```console
% bin/mruby -e 'Method = Proc; p Object.method(:inspect)'
zsh: segmentation fault (core dumped) bin/mruby -e 'Method = Proc; p Object.method(:inspect)'
```
After applying this patch, a `TypeError` exception will be raised.
```console
% bin/mruby -e 'Method = Proc; p Object.method(:inspect)'
trace (most recent call last):
[1] -e:1
-e:1:in method: allocation failure of Proc (TypeError)
```
However, if the `mrb_vtype` is the same object, the same care must still be taken as before.
```console
% bin/mruby -e 'Method = Binding; p method(:puts).eval("12345")'
trace (most recent call last):
[1] -e:1
-e:1:in eval: wrong argument type nil (expected Proc) (TypeError)
```
Since `Env` objects are shared by Blocks/Procs in the same context,
making multiple aliases in one context screws up with alias names.
New implementation uses alias bodies (Procs) to refer new names.
As a side effect, `__callee__` stop working correctly for aliases.
To fix this `__callee__` problem, we need to keep alias method names in
`callinfo`, which consumes more memory. We are wondering that is worth
the compatibility.
Calling `Class#allocate` with `UnboundMethod#bind_call` usually succeeds without problems.
If this behavior does not make us happy, we can now prohibit it with `MRB_SET_INSTANCE_TT(klass, MRB_TT_UNDEF)`.
At the same time, it applies to the `Binding`, `Complex`, `Data`, `Float`, `Integer`, `Method`, `Rational` and `UnboundMethod` classes.
Hoshiumi Arata