[Rd] too many arguments in foreign function call
Gregory R. Warnes
Fri, 13 Jul 2001 12:30:29 -0400
Duncan Templ Lang wrote:
> Gregory R. Warnes wrote:
> > Hi all,
> > Looking at the code in src/main/dotcode.c, I see that MAX_ARGS is set to
> > 65.
> > While it is possible to work around this limitation, it seems
> > arbitrary. I propose increasing the arbitrary value to 255 and adding
> > appropriate documentation to the Foreign manual page.
> > Any objections/comments?
> Unfortunately, it isn't quite as simple as that. The code that uses
> MAX_ARGS would also need to be extended and that involves adding the
> remaining cases to the switch statement in do_dotCode() and
> do_dotcall() in src/main/dotcode.c There's no reason why it can't be
> done. Somebody simply has to generate the appropriate code,
> presumably programmatically with a little script. I recall this was
> extended in S4, but 64 was adequate for that context.
> I imagine that there are some systems limit the number of arguments
> one can have to a routine.
OK. I wrote a little R script to generate the necessary case
statements. Since these code chunks are rather large (7140 lines
each!), I modifed src/main/dotcode to #include the case statements from
the (new) files /src/main/dotcode_cases.c and /src/main/dotcall_cases.c
. I'm not sure that this is the best way to do this, but including
these code chunks in dotcode.c makes it unmanagable.
While I was making and (this time) testing the changes, I noticed that
one declaration had the value 65 hardcoded rather than using MAX_ARGS.
I've uploaded a tgz file containing the patch and the R script that
generated the case statement/call code to
With this patch applied, the fortran subroutin I'm using now works fine
with 85 arguments. I imagine that it should be tested on several
platforms to ensure that there isn't (as Duncan menioned) that a problem
with compilers/platforms restricting the number of arguments.
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !) To: email@example.com