From duncan at wald.ucdavis.edu  Fri Oct  9 05:29:55 2009
From: duncan at wald.ucdavis.edu (Duncan Temple Lang)
Date: Thu, 08 Oct 2009 20:29:55 -0700
Subject: [Rd] R_CallMethodDef: 'type' and 'style' fields?
In-Reply-To: <25803313.post@talk.nabble.com>
References: <25803313.post@talk.nabble.com>
Message-ID: <4ACEAE33.8020903@wald.ucdavis.edu>



Steve Jaffe wrote:
> In Writing R Extensions it is said that R_CallMethodDef has two optional
> fields, 'type' and 'style' (where 'style' is said to distinguish
> in/out/inout arguments).

Can you point us to the particular section and line that says
this. I think it is for the R_CMethodDef structure, not the
R_CallMethodDef.


Indeed, in Rdynload.h

typedef enum {R_ARG_IN, R_ARG_OUT, R_ARG_IN_OUT, R_IRRELEVANT} R_NativeArgStyle;

/*

 These are very similar to those in  unix/dynload.c

 but we maintain them separately to give us more freedom to do

 some computations on the internal versions that are derived from

 these definitions.

*/
typedef struct {
    const char *name;
    DL_FUNC     fun;
    int         numArgs;

    R_NativePrimitiveArgType *types;
    R_NativeArgStyle         *styles;

} R_CMethodDef;

> But it doesn't give the possible values for
> 'style'.

The enum above does.
The types is described in the help file for .C or .Call, i.e.
?.C

> Looking at the header Rdynload.h (version 2.9.2) it appears that
> R_CallMethodDef  does not have these extra two fields. 

See above.

> 
> Were they removed at some point? If so, what is the best way to call a C
> function without the overhead of copying the inputs?

The .Call() interface does not copy the R objects that it passes to the
C routine which accepts SEXP type objects (and returns a SEXP object also).

 D.

> 
> Thanks



[Rd] R_CallMethodDef: 'type' and 'style' fields?
Duncan Temple Lang