В Mon, 29 Jul 2024 16:29:42 -0400
Toby Hocking <tdho...@gmail.com> пишет:
> Can you please clarify what input files should be used with your
> proposed function? I tried a few files in r-svn/src/include and one of
> them gave me an error.
This is a good illustration of the brittleness of the regexp approach.
I focused on the header files marked as API:
> tools:::funAPI()$loc |> unique() |> setdiff('WRE')
[1] "R_ext/GraphicsDevice.h" "Rmath.h"
[3] "R_ext/GraphicsEngine.h" "R_ext/BLAS.h"
[5] "R_ext/Lapack.h" "R_ext/Linpack.h"
[7] "Rembedded.h" "Rinterface.h"
[9] "R_ext/Altrep.h" "R_ext/Memory.h"
[11] "R_ext/RStartup.h" "R_ext/Arith.h"
[13] "R_ext/Random.h" "R_ext/Error.h"
I also wanted the function not to crash with Rinternals.h, but getdecl
/ getdecl2 / tools:::getFunsHdr all give different answers for it.
I think this can be done in a more reliable manner using a recursive
descent parser, but that would take some screenfuls of R that will need
to be very carefully written.
Speaking of discrepancies, here are a few functions declared in API
headers but marked with attribute_hidden:
R_ext/Error.h:NORET void WrongArgCount(const char *);
R_ext/Memory.h:int R_gc_running(void);
And some minor headaches for people who would like a full
programmatic list of entry points:
- The functions [dpq]norm are unconditionally remapped to dnorm4,
pnorm5, qnorm5, and the header file parser only picks up the
numbered function names.
- 'optimfn', 'optimgr', 'integr_fn' are marked in WRE as @apifun
despite not directly being functions or symbol names exported by R
binaries. May I suggest a separate category for types?
--
Best regards,
Ivan
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
