IEC 60559 single format has 6 to 9 significant decimal digits precision.
However the printf conversion specifier e (and E, of course) already
writes 1 digit - the one before the decimal point - and precision
specifies the number of digits to write after the decimal point.
No need to optimize since a program only exits once and errors are rare.
Also the mruby source code doesn't have these kind of checks elsewhere.
The ones in {Time,Random}#initialize are kept because there it actually
matters
since initialization always happens and re-initialization is unlikely.
If the argument is always a string, then mrb_str_cat_str() can be
directly called instead of indirectly by mrb_str_append().
mrb_any_to_s(), mrb_obj_as_string(), mrb_inspect() always return a
string.
thus "S!" means String|nil type. you have to check nil before
dereferencing the value. this is added to address #2882 while
keeping code simplicity. besides that current #2882 fix lose
polymorphism provided by mrb_get_args().
mrb_proc_new_cfunc_with_env() allocates RProc with RProc::env as NULL
then allocates REnv and sets it to RProc::env of the allocated RProc. If
incremental GC is ran before "allocates REnv and sets it to RProc::env
of the allocated RProc", the allocated RProc's GC status is
"marked" (Black) and the allocated REnv's GC status is
"unmarked" (White). The next incremental GC sweeps the allocated REnv
without re-marking the allocated RProc. Because the RProc is Black and
the REnv is White.
We need to implement write barrier for the case.
We can force to cause the above situation by the following patch:
diff --git a/src/proc.c b/src/proc.c
index f98998f..4f4e25c 100644
--- a/src/proc.c
+++ b/src/proc.c
@@ -92,6 +92,7 @@ mrb_proc_new_cfunc_with_env(mrb_state *mrb, mrb_func_t func, mrb_int argc, const
struct REnv *e;
int i;
+ mrb_incremental_gc(mrb);
p->env = e = env_new(mrb, argc);
MRB_ENV_UNSHARE_STACK(e);
e->stack = (mrb_value*)mrb_malloc(mrb, sizeof(mrb_value) * argc);
With this patch, "rake test" causes segmentation fault.
Dr Markus Kuhn published in 1999 an article [1] explaining in details
why we shouldn't use the ASCII grave accent (0x60) as a left quotation.
Backticks have been used most notably to produce nice-looking LaTeX
documents but it doesn't seem to be an issue on modern platforms and
for the oldest ones, there are workarounds as mentioned by Dr Kuhn.
[1]: https://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html
From the CRuby 2.2.2 Proc#arity documentation:
If the block has optional arguments, returns -n-1, where n is the number
of mandatory arguments, with the exception for blocks that are not
lambdas and have only a finite number of optional arguments; in this
latter case, returns n.
MIPS of Linux platform is supported frexpl(3).
This fixes to use the frexpl that are provided with gcc if user wants to build
on MIPS of Linux platform.
Signe-doff-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>