[R-pkg-devel] R_registerRoutines, etc.

[Rolf Turner]

On 23/04/17 21:57, Duncan Murdoch wrote:
> On 22/04/2017 5:25 PM, Rolf Turner wrote:

<SNIP>
>>
>> (1) I found that having an R function with the same name as that of a
>> routine (Fortran subroutine in this case) that it called, causes all
>> sorts of chaos.  I had a function "binsrt" that called a Fortran
>> subroutine named "binsrt" and a function "mnnd" that called a Fortran
>> subroutine named "mnnd".  This induced several fairly mysterious
>> warnings.  I resolved the issue by renaming the R functions "binsrtR"
>> and "mnndR" respectively, so as to eliminate the name conflict.
>>
>> Would this be the recommended procedure, or is there a cleverer way to
>> eliminate the problem?
>
> I think renaming the Fortran would make more sense:  the R routine may
> be used by your package users, whereas the Fortran routine may only be
> used by the R routine.  But there are probably lots of exceptions to this.

Hmmm.  Don't follow this.  Sorry to be slow.  It just seemed easier to 
me to fiddle with the R code than with the Fortran code.  I think I 
could go either way.

>> (2) The help for package_native_routine_registration_skeleton() says:
>>
>>> Optionally the skeleton will include declarations for the registered
>>> routines: they should be checked against the C/Fortran source code, not
>>> least as the number of arguments is taken from the R code. For .Call and
>>> .External calls they will often suffice, but for .C and .Fortran calls
>>> the void * arguments would ideally be replaced by the actual types.
>>
>> OTOH a post from Ege Rubak (answering a question like unto mine from
>> another user) basically says "Don't bother.  It doesn't really matter."
>>
>> However, being a Good Little Boy, I like to follow instructions exactly.
>>   So I tried to replace the "void *" strings by the "actual types", but
>> then all hell broke loose.  Consequently I went back to the "void *"
>> structures.  That appears to work, but:
>>
>>     (a) Are there any perils lurking if one just leaves "void *" as is,
>>         throughout?
>
> Not immediately, but a couple of potential ones:
>
>  - If you change the type of something in the future, "void *" won't
> care, but the compiler might catch a the change if you were more explicit.
>
>  - R CMD check generally becomes stricter over time, so it's possible it
> will complain about "void *" in the future.

Yeah, it was something like the latter that nagged the back of my mind. 
So I really would like to change the "void *" constructions.
Hence the following may be very helpful.

>>     (b) For the sake of completeness, how *does* one replace the "void *"
>>         constructions with "actual types" in a correct manner?
>>
>>          Example:  In my init.c file I currently have (as produced by
>>          package_native_routine_registration_skeleton()) :
>>
>>> extern void F77_NAME(mnnd)(void *, void *, void *, void *, void *);
>>
>>          The code in mnnd.f reads:
>>
>>> subroutine mnnd(x,y,n,dminbig,dminav)
>>> implicit double precision(a-h,o-z)
>>> .....
>>
>>          I.e. the "actual types are "double precision",
>>          "double precision", "integer", "double precision",
>>          "double precision".
>>
>>          So in this case I should (?) replace
>>
>>> extern void F77_NAME(mnnd)(void *, void *, void *, void *, void *);
>>
>>          by .... what?  Can anyone tell me?
>
> Looks like
>
> extern void F77_NAME(mnnd)(double *, double *, int *, double *, double *);
>
> to me.

Looks quite plausible.  I'll give it a try and report back.  (Later; not 
tonight, Josephine.  Past my bedtime. :-) )  My recollection is that I 
tried something like that, but said "integer" rather than "int".
Which is, I guess, Fortran-ese rather than C-ese.  And I guess the 
latter is called for.  In retrospect, I was being silly, since I said 
"double" (C-ese) rather than "double precision" (Fortran-ese).  So 
saying "int" would have been consistent.  Psigh!

Thanks.

cheers,

Rolf

-- 
Technical Editor ANZJS
Department of Statistics
University of Auckland
Phone: +64-9-373-7599 ext. 88276