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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._