`mrb_equal()` may call `obj.==` method internally.
Therefore, using an unupdated pointer and length after `mrb_equal()` could result in a read/write to an invalid address.
Fresh properties must always be obtained regardless of the result of `mrb_equal()`.
Also, `ary_modify()` must be called each time before writing.
ref. #6339
In some environments, the test will fail because the directory in use cannot be deleted.
This problem was encountered when building 32-bit binary with mingw32 on FreeBSD and running on wine.
Suppress warnings for 0-length sequences is not required.
By commit f1a02dff58, it was introduced.
By commit 24939723d7, pseudo-variable length arrays are now used and the warning suppression is no longer needed.
By commit e8841fbf58, moved the intervening code.
The C local variable is not protected from GC, so we use the function
mrb_gc_protect() to keep the value. We also keep the arena position by
mrb_gc_arena_save(), then restoring the position for every new return
value, to minimize arena size.
Small cosmetic changes (pre-increment to post-increment) are also made
in this commit.
When calling `mrb_equal()` or `mrb_funcall()` family functions, the GC arena should be restored if the loop is repeated by a non-immediate return value.
In my opinion, restoring the GC arena is unnecessary when a non-immediate (true) value causes the function to return (e.g. the `mrb_ary_index_m()` function).
The patch does not take into account the case of recursive calls and may be incomplete.
We assumed there's no need for gc_arena_keep() when MRB_GC_FIXED_ARENA
is set. But it turned out that gc_protect() still can cause use-after-free
with fixed arena.
Revert "gc.c (gc_protect): should not call gc_arena_keep twice from allocation"
This reverts commit 28ece4ed8b.
Revert "gc.c (gc_arena_keep): reorganized for MRB_GC_FIXED_ARENA; ref #6329"
This reverts commit 33dd623a02.
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
“mruby-compiler” should be able to generate `y.tab.c` files through a separate build configuration if it is not added to the ‘host’ build.
In the example above, the “host/mrbc” build should generate the `y.tab.c` file.
When GC occurs during the expansion of the GC arena by `gc_protect()` in `mrb_obj_alloc()`, the object page just allocated by `add_heap()` is released.
Therefore, as soon as control returns from `gc_protect()`, there is a possibility of illegal writing or reading to the address just released.
This issue was discovered during the investigation of #6326.
Yukihiro "Matz" Matsumoto