A potential solution, at least in terms of producing the desired output, is the
base R function alist:
> alist(1+2, "a", rnorm(3))
[[1]]
1 + 2
[[2]]
[1] "a"
[[3]]
rnorm(3)
> str(alist(1+2, "a", rnorm(3)))
List of 3
$ : language 1 + 2
$ : chr "a"
$ : language rnorm(3)
luke
[[altern
Hello,
If you want to determine where the warning is generated, I think it's easiest
to run R with options(warn=2).
In that case all warnings are converted to errors, and you have more debugging
tools, e.g. you can run traceback() to see the calling stack, or use
options(error=recover).
Hope yo
Hi
In my R package, imagine I have a C function defined:
void myfunc(int *x) {
// some code
}
but when I call it, I pass it a pointer to a longint instead of a
pointer to an int. Could this practice potentially result in a segfault?
Regards
Ben
__
On 15/08/2018 7:08 AM, Benjamin Tyner wrote:
Hi
In my R package, imagine I have a C function defined:
void myfunc(int *x) {
// some code
}
but when I call it, I pass it a pointer to a longint instead of a
pointer to an int. Could this practice potentially result in a segfault
Assuming you are fine with a pairlist instead of a list avoiding the
`as.list()` call for dots2 saves a reasonable amount of time and makes it
clearly the fastest.
library(rlang)
dots1 <- function(...) as.list(substitute(list(...)))[-1L]
dots2 <- function(...) as.list(substitute(...()))
dots2.5 <
> On 15 Aug 2018, at 12:48, Duncan Murdoch wrote:
>
>> On 15/08/2018 7:08 AM, Benjamin Tyner wrote:
>> Hi
>> In my R package, imagine I have a C function defined:
>> void myfunc(int *x) {
>>// some code
>> }
>> but when I call it, I pass it a pointer to a longint instead of a
>
That was my first thought (my second was trace(.Deprecated,...)). However,
the spam authors don't use .Deprecated() or warning() to tell about
deprecated functions. See spam/R/deprecated.R:
validspamobject <- function( ...) {
#.Deprecated('validate_spam()')
message("`validspamobject()` i
No segfault but a BIG warning from the compiler. That's because
dereferencing the pointer inside your myfunc() function will
produce an int that is not predictable i.e. it is system-dependent.
Its value will depend on sizeof(long int) (which is not
guaranteed to be 8) and on the endianness of the
Thanks for the replies and for confirming my suspicion.
Interestingly, src/include/S.h uses a trick:
#define longint int
and so does the nlme package (within src/init.c).
On 08/15/2018 02:47 PM, Hervé Pagès wrote:
No segfault but a BIG warning from the compiler. That's because
dereferencin
Note that include/S.h contains
/*
This is a legacy header and no longer documented.
Code using it should be converted to use R.h
*/
...
/* is this a good idea? - conflicts with many versions of f2c.h */
# define longint int
S.h was meant to be used while converting to R C code
10 matches
Mail list logo
