[Rd] Inconsistent behavior for the C AP's R_ParseVector() ?
|g@ut|er @end|ng |rom gm@||@com
Sat Nov 30 23:55:43 CET 2019
Beside R_ParseVector()'s possible inconsistent behavior, R's handling of
zero-length named elements does not seem consistent either:
> lst <- list()
> lst[[""]] <- 1
> list("" = 1)
Error: attempt to use zero-length variable name
Should the parser be made to accept as valid what is otherwise possible
when using `[[<` ?
Le sam. 30 nov. 2019 à 17:33, Laurent Gautier <lgautier using gmail.com> a écrit :
> I found the following code comment in `src/main/gram.c`:
> /* Memory leak
> yyparse(), as generated by bison, allocates extra space for the parser
> stack using malloc(). Unfortunately this means that there is a memory
> leak in case of an R error (long-jump). In principle, we could define
> yyoverflow() to relocate the parser stacks for bison and allocate say on
> the R heap, but yyoverflow() is undocumented and somewhat complicated
> (we would have to replicate some macros from the generated parser here).
> The same problem exists at least in the Rd and LaTeX parsers in tools.
> Could this be related to be issue ?
> Le sam. 30 nov. 2019 à 14:04, Laurent Gautier <lgautier using gmail.com> a
> écrit :
>> The behavior of
>> SEXP R_ParseVector(SEXP, int, ParseStatus *, SEXP);
>> defined in `src/include/R_ext/Parse.h` appears to be inconsistent
>> depending on the string to be parsed.
>> Trying to parse a string such as `"list(''=1+"` sets the
>> `ParseStatus` to incomplete parsing error but trying to parse
>> `"list(''=123"` will result in R sending a message to the console (followed but a crash):
>> R[write to console]: Error: attempt to use zero-length variable nameR[write to console]: Fatal error: unable to initialize the JIT*** stack smashing detected ***: <unknown> terminated
>> Is there a reason for the difference in behavior, and is there a workaround ?
[[alternative HTML version deleted]]
More information about the R-devel