alloc

Douglas Bates bates@stat.wisc.edu
21 Jan 1998 11:58:20 -0600


Paul Gilbert <pgilbert@bank-banque-canada.ca> writes:

> I am trying to get our database interface (PADI) working with R. The code does
> some memory allocation and for Splus there is an ifdef which controls whether
> malloc or S_alloc is called. I did  nm R.binary | grep alloc to see if this was
> supported and I find there are some choices:
> [2490] |    446036|     272|FUNC |GLOB |0    |7      |R_alloc
> [806] |    693956|     312|FUNC |LOCL |0    |7      |ReallocString
> [807] |    693220|     736|FUNC |LOCL |0    |7      |ReallocVector
> [3444] |    446308|     144|FUNC |GLOB |0    |7      |S_alloc
> [2429] |    446452|     200|FUNC |GLOB |0    |7      |S_realloc
> ...
> [2204] |   1445856|       0|FUNC |GLOB |0    |UNDEF  |calloc
> [2595] |   1444644|       0|FUNC |GLOB |0    |UNDEF  |malloc
> [3066] |   1444728|       0|FUNC |GLOB |0    |UNDEF  |realloc
> ...
> Is there any advantage to calling R_alloc rather than S_alloc? I also see that
> malloc is UNDEF. Now I'm not a C programmer, but I have a funny feeling that
> this could lead to some problems?

I can't answer the first question but the second one is not a problem.
The UNDEF here means that these symbols not defined in the R.binary
file.  They are defined in the libc.so shared object which will be
linked at run time.  This is the basic idea of shared libraries - all
the processes that running and use malloc, for example, use the same
copy of this function.  It is dynamically linked and shared between
the processes.
-- 
Douglas Bates                            bates@stat.wisc.edu
Statistics Department                    608/262-2598
University of Wisconsin - Madison        http://www.stat.wisc.edu/~bates/
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._