definition of R_problem_buf in S.h (PR#210)
Guido Masarotto
guido@hal.stat.unipd.it (Guido Masarotto)
Mon, 14 Jun 1999 19:30:48 +0100
On Mon, Jun 14, 1999 at 06:30:42PM +0200, Martin Maechler wrote:
> >>>>> On Mon, 14 Jun 1999 17:56:06 +0200 (MET DST), vogels@ieee.org said:
>
> vogels> Full_Name: Thomas Vogels Version: 0.64.1 OS: AIX 4.2 Submission
> vogels> from: (NULL) (198.133.22.70)
>
>
> vogels> R_problem_buf is defined, not just declared, in S.h:
>
> vogels> #define R_PROBLEM_BUFSIZE 4096 char
> vogels> R_problem_buf[R_PROBLEM_BUFSIZE];
>
> vogels> This is bad since every time S.h is included this buffer is
> vogels> defined. The linker will eventually complain about multiple
> vogels> definitions of this symbol.
> no.
> All our include files ``idempotent'' : Including them multiple times
> doesn't change anything.
Yes, but what happens if different files to be linked in the same
shared library include S.h? If I understand the behaviour is
linker dependent.
>
> vogels> Solution: declare R_problem_buf to be extern in S.h, then
> vogels> allocate memory for it in a source file, like main.c with: char
> vogels> R_problem_buf[R_PROBLEM_BUFSIZE];
>
> Not the real solution, main.c does not even include S.h !
>
R.binary exports R_problem_buf since S.h is includes by appl/loglin.c.
Anyway, going toward a multi-threaded R, I agree with Martin that
this is not the solution.
What about declaring R_problem_buf static?
guido
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._