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

[Peter Dalgaard BSA]

Guido Masarotto <guido@hal.stat.unipd.it> writes:

>   Allocating the buffer *inside* the function is easy if we insist
>   on the PROBLEM ....RECOVER interface (but K. has another opinion):

Yes. I think Kurt is missing the point that S.h is a *compatibility*
item, so we're stuck with whatever ugliness that is present in S. It
is still allowed to do it neater.

>   #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?

I don't think so... 

Let's see: This would create R_problem_buf on the stack when PROBLEM
is encountered or when the function is called? (Forgetting my C
semantics...). In either case, we certainly avoid the reentrancy
problem. In the latter (unlikely) case, we waste 4k per potential
PROBLEM, which is hardly a problem unless the function is heavily
recursive. Sounds good.

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