It isn't needed as it's very similar to mrb_define_method_raw() and also
there's only one place where mrb_proc_ptr() actually has to be called.
Inspired by @furunkel's method cache patch (#2764).
The format specifier macros were needed to portably print a mrb_int,
because mrb_raisef() originally called vsnprintf(). It doesn't anymore
since 18b2683b97 and the mrb_int format
specifier macros are already gone.
The new implementation is backwards incompatible, but I couldn't find
any usage outside mruby and I also couldn't think of a different and
good name.
All ISO C99 printf conversion specifiers for floating point numbers and
an optional precision are supported.
It is largely based on code from the MIT licensed musl libc
(http://www.musl-libc.org/) and its floating point printing is exact
(unlike the current code behind Float#to_s).
`mruby -b` now accepts both big/little endian mrb (compiled binary) files.
`mrbc` generates mrb files in big endian for .mrb files and in native endian
for C files (with -B option specified) by default. If you are cross compiling,
you need to specify target endian by -e/-E options if it is different from
host endian.
Add padding bytes before iseq block that may be used as mrb_code[].
Note that dumped mrb format has changed.
Based on a patch from kimu_shu <alfvegardrisc@gmail.com>
b72e94f used _etext and _edata to distinguish C string literals from heap allocated strings,
but using _edata, global char arrays may be considered as string literals. to avoid the issue,
we have to use __init_array_start, which might be less portable. you can still use _edata, by
using MRB_NO_INIT_ARRAY_START.
on platforms with _etext and _edata, mruby can distinguish string literals so that it avoids memory allocation to copy them.
for example, on my Linux box (x86 32bit), memory consumed by mrbtest decreased from 8,168,203 to 8,078,848 (reduced 88KB).
if you see compiler errors due to this commit, you'd better to use array-modifying
functions, e.g. mrb_ary_set() or mrb_ary_push(), otherwise you might see nasty
GC bugs in the future. if you are sure what you are doing, replace `RARRAY_PTR(ary)`
by `mrb_ary_ptr(ary)->ptr`. but be warned.
_snprintf is not C99's snprintf!
This simple implementation, unlike _snprintf,
always null-terminates and returns the expected
return value (in most cases).
Other C99 behaviors (like format specifiers) require
adding a complete snprintf implementation.
Do we want or need that?
The same applies to vsnprintf (aka _vsnprintf).
take_cheeze