definition of R_problem_buf in S.h (PR#210)

[Guido Masarotto]

On Mon, Jun 14, 1999 at 08:03:02PM +0200, Peter Dalgaard BSA wrote:
> 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...?

  Allocating the buffer *inside* the function is easy if we insist
  on the PROBLEM ....RECOVER interface (but K. has another opinion):
  #define PROBLEM {char R_problem_buf[R_PROBLEM_BUFSIZE];\
                   sprintf(R_problem_buf,
  #define RECOVER(x)      ), error(R_problem_buf); }

  Same for WARNING
  Are there other use of the buffer?
  g.


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