After 5e86b005c0, I now think ANYARGS is
dangerous and should be extinct. This commit deletes ANYARGS from
rb_ensure, which also revealed many arity / type mismatches.
After 5e86b005c0, I now think ANYARGS is
dangerous and should be extinct. This commit deletes ANYARGS from
rb_rescue / rb_rescue2, which revealed many arity / type mismatches.
After 5e86b005c0, I now think ANYARGS is
dangerous and should be extinct. This commit deletes ANYARGS from
struct vm_ifunc, but in doing so we also have to decouple the usage
of this struct in compile.c, which (I think) is an abuse of ANYARGS.
After 5e86b005c0, I now think ANYARGS is
dangerous and should be extinct. Let's start from making
rb_block_call_func_t strict, and apply RB_BLOCK_CALL_FUNC_ARGLIST liberally.
```
In file included from sprintf.c:1256:
./vsnprintf.c:833:8: warning: adding 'int' to a string does not append to the string [-Wstring-plus-int]
IS_PRI_EXTRA_MARK(fmt)) {
^~~~~~~~~~~~~~~~~~~~~~
./vsnprintf.c:826:34: note: expanded from macro 'IS_PRI_EXTRA_MARK'
strncmp((s)+1, PRI_EXTRA_MARK+1, \
~~~~~~~~~~~~~~^~
./vsnprintf.c:833:8: note: use array indexing to silence this warning
./vsnprintf.c:826:34: note: expanded from macro 'IS_PRI_EXTRA_MARK'
strncmp((s)+1, PRI_EXTRA_MARK+1, \
^
1 warning generated.
```
I'm afraid the keys to this hash are just integers, and those integers
may look like VALUE pointers when they are not. Since we don't mark the
keys to this hash, it's probably safe to say that none of them have
moved, so we shouldn't try to update the references either.
Flags for ruby core such as warning and `_FORTIFY_SOURCE` macro
are not necessary to make fake.rb, except for `RUBY_EXPORT` macro
which prevents to include ruby/backward.h.
Often uid / gid are 16 bit or 32 bit integers, while VALUE are 32
to 64 bits. They tend to differ in size. Because rb_ensure expects
its callbacks to take VALUE arguments, narrowing must be done by
hand, otherwise data corruption can happen depending on machine ABI.