search for: otherdefs

...king up my custom xrealloc, but using an xrealloc provided by R. Besides the fact that I am linking to the wrong xrealloc, I think my tests are failing for the same reason that the following code segfaults on Linux (Debian, with R 3.4.0): test <- inline::cfunction(language='C', otherdefs='void *xmalloc(size_t); void *xrealloc(void *, size_t);', body = 'void *ptr = xmalloc(256); xrealloc(ptr, 0); return R_NilValue;') test() ## xrealloc: out of virtual memory It seems that the R xrealloc doesn't like being given a size of 0, even though this behavior is we...

...ut using an xrealloc provided by R. > > Besides the fact that I am linking to the wrong xrealloc, I think my > tests are failing for the same reason that the following code > segfaults on Linux (Debian, with R 3.4.0): > > test <- inline::cfunction(language='C', > otherdefs='void *xmalloc(size_t); void *xrealloc(void *, size_t);', > body = 'void *ptr = xmalloc(256); xrealloc(ptr, 0); return > R_NilValue;') > test() > ## xrealloc: out of virtual memory > > It seems that the R xrealloc doesn't like being given a size of 0, >...

On 11 May 2017 at 12:16, Patrick Perry wrote: | I've done a bit more investigation into this issue. Here is my current | understanding of the situation: | | 1. I have a package on CRAN (corpus-0.3.1) that passes tests on all | platforms except for Linux. | 2. My package defines a C function, "xrealloc", for internal use. | 3. The libreadline library that R links to defines a

Henrik, the whole point and only purpose of mc* functions is to fork. That's what the multicore package was about, so if you don't want to fork, don't use mc* functions - they don't have any other purpose. I really fail to see the point - if you use mc* functions you're very explicitly asking for forking - so your argument is like saying that print() should have an option to