The changes at b2c3d88f were inappropriate because the memory layout of bit
fields are implementation defined. Therefor, I fixed it not to use bit
fields.
The default implementation of `mrb_immediate_p` uses `mrb_type`. However,
in `MRB_WORD_BOXING`, `mrb_type` has many branches and is inefficient, so
provide an implementation that does not use `mrb_type`.
On 64-bit CPU, there is padding in `RBasic`, so reorder the fields and use
it as buffer of embedded string. This change allows 4 more bytes to be
embedded on 64-bit CPU.
However, an incompatibility will occur if `RString::as::ary` is accessed
directly because `RString` structure has changed.
When building WebAssembly targets with clang (e.g. wasm32-unknown-unknown), all
symbols are hidden by default. To export a symbol, it must be marked with
__attribute__((visibility(default)))
Rather than detecting this exotic target in mruby, allow MRB_API to be defined
externally.
`mrb_string_value_cstr` and `mrb_string_value_len`: obsolete
`mrb_string_cstr`: new function to retrieve NULL terminated C string
`RSTRING_CSTR`: wrapper macro of `mrb_string_cstr`
Normal `TYPED_FIXABLE(f,mrb_float)` does not work on 64bit int from
casting problems. The new approach works well, but assumes two's
complement and IEEE-754 floating point numbers.
In #4550, @shuuji proposed the name name `MRB_STR_NO_MULTI_BYTE` for
more precise description. Although I agree that the name name is
correct, but the flag means the string does not contain multi byte UTF-8
characters, i.e. all characters fit in the range of ASCII.
Example:
$ bin/mruby -e '
p "あa".byteslice(1)
p "bar".byteslice(3)
p "bar".byteslice(4..0)
'
Before this patch:
"a"
""
RangeError (4..0 out of range)
After this patch (same as Ruby):
"\x81"
nil
nil
Before this patch:
$ bin/mruby -e 'p Struct.new("A-")'
#=> Struct::"A-"
After this patch:
$ bin/mruby -e 'p Struct.new("A-")'
#=> NameError: identifier A- needs to be constant
This time, the allocated memory comes from the string object, which is
referenced from GC arena. The memory region will be reclaimed when the C
function called from VM is terminated, or the GC arena is restored.
When I found this function, I expected it to behave the same as the
`alloca(3)` function, but it is accually the `mrb_alloca()` function
does not free the heap until the `mrb_close()` function is called.
Also, even if it is deleted, it can be replaced with the combination
of the `MRB_TT_DATA` object and the `mrb_gv_set()` function if it is
sure necessary.
KOBAYASHI Shuji