Full_Name: Thomas Vogels Version: 0.64.1 OS: AIX 4.2 Submission from: (NULL) (198.133.22.70) R_problem_buf is defined, not just declared, in S.h: #define R_PROBLEM_BUFSIZE 4096 char R_problem_buf[R_PROBLEM_BUFSIZE]; This is bad since every time S.h is included this buffer is defined. The linker will eventually complain about multiple definitions of this symbol. Solution: declare R_problem_buf to be extern in S.h, then allocate memory for it in a source file, like main.c with: char R_problem_buf[R_PROBLEM_BUFSIZE]; -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- 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 _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
>>>>> 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. This protection is *very* standard and is achieved by (for the case of S.h) #ifndef R_S_H #define R_S_H .................. everything ...... #endif 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-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 _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
I think Thomas is correct and that it is a problem. I brought it up a
while back and Peter had some comments. The problem is when 2 or more
user-level C source files include S.h. Then while each file has an
idempotent S.h, when linked together, there is a duplication of
symbols. The problem is not within source file but across file.
D.
_______________________________________________________________
Duncan Temple Lang duncan@research.bell-labs.com
Bell Labs, Lucent Technologies office: (908)582-3217
700 Mountain Avenue, Room 2C-259 fax: (908)582-3340
Murray Hill, NJ 07974-2070
http://cm.bell-labs.com/stat/duncan
Languages shape the way we think, and determine what
we can think about -- Benjamin Whorf
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
Duncan Temple Lang <duncan@rice.research.bell-labs.com> writes:> I would vote for (2). If we go to multiple evaluators as some of us > were discussing recently, evaluator-specific statics will need to be > removed.Hm. That won't help, will it? We'd have one static object instead of several. If threads try to step on eachothers toes it wouldn't prevent it, just allow them to do it from within different functions! What one would really need is a way to generate the buffer dynamically *inside* the function call. Or setup PROBLEM to do some kind of resource locking, in which case it doesn't really matter whether we use (1) or (2)? Or...? -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- 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 _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
> > Duncan Temple Lang <duncan@rice.research.bell-labs.com> writes: > > > I would vote for (2). If we go to multiple evaluators as some of us > > were discussing recently, evaluator-specific statics will need to be > > removed. > > Hm. That won't help, will it? We'd have one static object instead > of several. If threads try to step on eachothers toes it wouldn't > prevent it, just allow them to do it from within different functions! > > What one would really need is a way to generate the buffer > dynamically *inside* the function call. Or setup PROBLEM to do some > kind of resource locking, in which case it doesn't really matter > whether we use (1) or (2)? Or...? >Absolutely. I was just thinking of not having many statics but that we could deal with a single one by adding it to the Evaluator structure. In this way, there is a single one per evaluator and at present this is adequate. If we need more, we introduce a stack or linked list. If we dynamically generate the buffer in the call, then we will have to change the arguments, etc. to pass it out to other routines. Otherwise, if we use the statics to communicate the new buffer we are no better off, except for the dynamic allocation avoiding the buffer overflow. Robert will likely be doing things with all of this via his exception/handler mechanism also. -- _______________________________________________________________ Duncan Temple Lang duncan@research.bell-labs.com Bell Labs, Lucent Technologies office: (908)582-3217 700 Mountain Avenue, Room 2C-259 fax: (908)582-3340 Murray Hill, NJ 07974-2070 http://cm.bell-labs.com/stat/duncan Languages shape the way we think, and determine what we can think about -- Benjamin Whorf -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- 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 _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._