`mrb_get_arg1()` raises `ArgumentError` if the method does not receive one
argument.
And replaces all `mrb_get_args(mrb, "o", &arg)` by the new function.
Consecutive `_` is not allowed as a numeric expression:
1_2__3 #=> SyntaxError
Float("1_2__3") #=> ArgumentError
Integer("1_2__3") #=> ArgumentError
"1_2__3".to_i #=> 12
But `String#to_f` accept it, so I fixed the issue.
Before this patch:
"1_2__3".to_f #=> 123
After this patch:
"1_2__3".to_f #=> 12
The binary sizes (gems are only `mruby-bin-mruby`) are reduced slightly in
my environment than before the introduction of new specifiers/modifiers
(5116789a) with this change.
------------+-------------------+-------------------+--------
BINARY | BEFORE (5116789a) | AFTER (This PR) | RATIO
------------+-------------------+-------------------+--------
mruby | 593416 bytes | 593208 bytes | -0.04%
libmruby.a | 769048 bytes | 767264 bytes | -0.23%
------------+-------------------+-------------------+--------
BTW, I accidentally changed `tasks/toolchains/visualcpp.rake` at #4613,
so I put it back.
We have added internal convenience method `__to_str` which
does string type check.
The issue #3854 was fixed but fundamental flaw of lack of stack
depth check along with fibers still remains. Use `MRB_GC_FIXED_ARENA`
for workaround.
The ISO standard does not include implicit type conversion using
`to_int`. This implicit conversion often causes vulnerability.
There will be no more attacks like #4120.
In addition, we have added internal convenience method `__to_int` which
does type check and conversion (from floats).
The new API is:
int mrb_range_beg_len(mrb, range, &beg, &len, len, trunc)
The new argument `trunc` is a boolean value that specifies
whether the function truncates the range. The new return value
is an integer instead of a boolean, that is:
0: not a range
1: range with proper edges
2: out of range
To get the old behavior, you have to rewrite:
mrb_range_beg_len(mrb, range, &beg, &len, len)
to:
mrn_range_beg_len(mrb, range, &beg, &len, len, TRUE) == 1
[Breaking Change]