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

[Kurt Hornik]

>>>>> Peter Dalgaard BSA writes:

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

Hmm.  Is everyone trying to give me a hard time lately?  I am aware that
it is there for compatibility.  I was trying to say that even if we keep
the interface supported, we should still find a better way AND advertize
it accordingly.

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

In any case, let me get rid of this in appl/loglin.c.  On a related
issue, what is the recommended way of allocating memory in such files,
via Calloc()?

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